용어 "순수한 OO 언어"에 대한 공식적인 정의?

나는 그런 질문을 던질 SO 형제들 사이에서 더 좋은 곳을 생각할 수 없습니다. 원래 저는 "파이썬이 순수한 OO 언어입니까?" 그러나 용어를 정의하는 동안 사람들이 겪는 어려움과 불편 함을 고려하면서 용어 자체에 대한 명확한 정의를 얻는 것으로 시작하기로 결정했습니다.

앨런 케이 (Alan Kay) 박사의 서신 으로 시작 하는 것이 오히려 공평 할 것이다 (생물학적 유추에서 세포 나 다른 생물체에 대한 영감을 주목하라).

작업에 접근하는 방법은 다음과 같습니다.

1. 스몰 토크, 스칼라, 자바 등 의 용어를 정의하기에 독특하고 충분한 특정 속성을 보여줄 수있는 (또는 그렇게하지 못하는) 프로그래밍 언어를 나열하여 비교 분석을 제공합니다 (Smalltalk, Scala, Java 등은 가능하지만 예제는 가능하지만 IMO는 실제로 완전한 것으로 보이지는 않습니다) 유익 하지도 않음 )
2. 공식적인 정의를 제공하십시오 (또는 더 학문적 또는 수학적 스타일로).
3. 구체적인 언어의 의미 론적 맥락 또는 사전 프로그래밍 경험에 전적으로 의존하는 철학적 정의를 제공하십시오 (커뮤니티가 성공적으로 설명 할 기회가 있어야 함).

현재 버전 : " 작업과 피연산자를 ( 문법적으로 ) 구별 할 수 있고 각 피연산자의 유형에 대해 유추 할 수 있는 특정 프로그래밍 ( 공식 ) 언어 가이 유형이 객체인지 (OOP의 의미) 아닌지 여부 이 언어에는 객체 인 하나 이상의 유형이있는 한 이러한 언어를 OO 언어로 사용할 수 있습니다. 마지막으로, 모든 언어 유형이 객체 인 경우 이러한 언어를 순수 (강한) OO 언어로 정의합니다. "

가능한 개선을 부탁드립니다. 보다시피 방금 정의를 "객체"라는 용어에 의존하게 만들었습니다.

[편집하다]

또한 유형 언어와 마찬가지로 유형의 개념을 사용합니다 . 데이터 유형 프로그래밍 또는 유형 지향 프로그래밍은 (프로그램 텍스트, 즉 리터럴 및 데이터 변수의 특정 값을 처리하는 방법-유형 안전성으로 발전하는 방법)의 구문 해석 일뿐 아니라 언어 문법에 기인하고 공식적인 방식으로 연구 될 수 있습니다 (수학적 논리 사용) 소위 type systems . 특정 유형 시스템에 소위 범용 유형 을 요구하는 것이 OO 언어의 순도를 정의하는 방법 중 하나입니다 (이를 의미 적으로 확장하는 방법이 있음).

NB

대답하는 방법 :

• 용어 및 개념에 대한 이해를 지원 / 설명하는 책 또는 참조를 지정하면 도움이됩니다 (일반적으로 좋은 정의는 기본을 제외한 모든 종속 개념을 다루거나 참조합니다).
• 가능하다면 답변 / 정의의 들여 쓰기 범주를 명확하게 명시하지 않은 경우 표시하십시오 (위 참조 : 1-언어 예, 2-수학 논리, 3-기술 설명 및 프로그래밍 철학)
• 분류가 중요 unmix 다른 공지 된 방법에서 OO 패러다임 요소 (없고 의해 시도 응답 상태 (기간 순수 OO이 용어 OO에 포함되어 또한 때문에) 혼동은 / 오버랩 그들을 예는 일반적 요소 모듈성이 커버 될 수있다 OO 프로그래밍으로 구현) : OOP와 기능 프로그래밍, 논리적 프로그래밍 (특히 강력하게 특수화 된), Abstarct Data Types (ADT), Modular, Metaprogramming (일반 및 LISP의 매크로 확장 시간)과 OOP를 구별하십시오. 계약 (예 : 에펠), 측면 지향 (AO), (선언적, 기능적 분류와 Dijkstra의 구조적 정의에 대한 역사적 정의가 명확함)

공식적인 정의를 내리기가 어렵다 : 놀랍게도 충분한 논리 (형식) 시스템 (대부분 유형 기반)의 형태로 OOP에 대한 수학적 설명을 제공하고 하나의 개념을 차례로 정의하는 것은 매우 쉽다. 심지어추상적 인 오락 이나 운동보다는 형식 안전 검사 또는 새로운 언어 디자인 측면에 형식주의를 적용하여 더 실용적인 무언가를 시도 할 수도 있습니다( 직관적 유형 이론 , 종속 유형 , 독립적으로 람다 미적분학으로 FOL 형식주의에서OOP의 조회 구성)카테고리 이론을 사용하여). 여기서 중요한 점은 의심 할 여지없이어쩌면 일정 비율의 발견을 제외하고 - 같은 제형은 IMO 강하게 가능성이 처음 불완전 (컴퓨터 공학) OOP의 이해 및 이후 거의 액세스 할 수있는 (따라서 거의 프로그래밍 세계에 뒤로 기여하지 결국 대부분의 지역에서 (결함) 바이어스되는 응용 프로그램의 존재에 의해 공식적으로 세계에서 백업 대중적인 언어로 통합 ).

그렇습니다. 정의 만이 아니라 "좋은"정의를 정확하게 제시하기는 어렵습니다. 그러나 나는 당신의 경험과 직접적인 개입 때문에 여기에 이것을 묻는 것에 긍정적입니다.

OO, Alan Kay에 따르면 메시지 전달에 관한 것이 전부입니다. 다형성 및 캡슐화와 같은 품질은 실제로 메시지 전달에서 파생됩니다.

기본적으로 스몰 토크와 언어 만 비슷하다는 의미이기 때문에이 자세는 실제로 매우 극단적입니다.

OO를 엔티티에 시스템을 구축하고 상태를 완전히 캡슐화하며 고유 한 다형성 특성으로 인해 교환 가능하게 만드는 것으로 정의 할 수 있다고 생각합니다. 따라서 순수 OO 언어는이 두 가지 핵심 특성이 항상 충족되도록 보장 할 수 있습니다. OO 언어를 "불순"하게 만드는 것은 다음과 같은 가능성과 같이 이러한 기준을 충족하지 않는 구문을 만들 수있는 메커니즘입니다.

• 퍼블릭 필드 선언
• 특정 클래스와 그 서브 클래스의 인스턴스 만 보유 할 수있는 변수 선언 다형성의 여지가 훨씬 적습니다.
• 프리미티브 선언

다시 IMHO 언어 순도는 강점보다 약점입니다. OO는 은색 총알이 아닙니다. 단일 패러다임은 없습니다.

나는 이것을 OOP 구문을 사용하는 언어로 정의하고 다른 것은 아무것도 없다 (순수한 FP 언어가 불변의 데이터와 함께 순수한 함수를 사용하는 것과 같은 방식으로).

특히:

• 프로그램이 작동하는 모든 엔티티는 첫 번째 클래스 객체입니다 . 즉 프리미티브, 포인터, 배열이 없습니다.
• 객체로 할 수 있는 유일한 것은 객체에 (잠재적으로 다형성) 메소드를 호출하는 것입니다 (== 메시지 보내기). 다른 작업이 없습니다.
• 모든 데이터는 캡슐화되어 있습니다 . 즉 공개 필드 액세스가 없으므로 개체의 메서드를 거쳐야합니다.
• 퍼스트 클래스 함수를 가지고 있다면 그것들도 객체 여야합니다. 따라서 다음과 같은 작업을 수행해야합니다.functionObject.call(param1,param2)
• 전역 변수가 없음 -이와 같은 것을 원하면 현재 전역 환경을 표현하기 위해 객체를 사용해야합니다 (예 : environment.getValue("myThing")변수를 클래스 객체에 넣음)

이것은 여전히 ​​몇 가지 옵션을 열어 둡니다.

• 클래스 기반 및 프로토 타입 기반 개체 모델
• 상속이 어떻게 구현 되는가
• 메소드에 단일 또는 다중 디스패치가 있는지 여부
• 객체가 정적으로 또는 동적으로 유형화되는지 여부
• 메소드 호출에 사용되는 정확한 구문 (예 : getter / setter 등을위한 구문 설탕이있을 수 있음)

소위 OO 언어에 대한 논의는 항상 세뇌 된 측면에서 약간 이루어졌습니다. 즉 :

"누군가는 언어 X가 OO라고 말했기 때문에 언어 X가 OO라고 말하면 언어 X의 기능이없는 모든 언어는 OO 일 수 없습니다. 그리고 언어 X로 코드를 작성하기 때문에 내가하는 모든 일은 OO입니다. "

객체 지향 디자인이라는 용어는 3 가지로 요약됩니다.

1. 프로그램의 나머지 부분에 대한 불필요한 정보를 알 수없는 자율적 객체를 사용한 모듈 식 설계 ( 가능한 한 느슨한 커플 링 ).
2. 의도적이거나 우발적 인 외부 액세스를 방지하기 위해 객체 내부에 데이터를 캡슐화합니다.
3. 객체 사이의 명확한 종속성. 느슨한 결합을 달성 할뿐만 아니라 프로그램을보다 쉽게 ​​유지 보수 및 확장 할 수 있습니다.

1) 순수한 프로그램 디자인, 그것은 어떤 프로그래밍 언어로 달성 될 수 있습니다. 그러나 일부 언어에는 class / struct 및 개인 키워드와 같은 유용한 기능이 있습니다.

2) 주로 프로그램 설계이지만, 언어 지원 없이는 완전히 달성 할 수 없습니다. 실수로 사용하지 않도록 개인 / 정적과 같은 언어 메커니즘이 필요하기 때문입니다.

3) 주로 프로그램 디자인입니다. 일반적으로 "개체 X에 개체 Y가 포함되어 있음", "개체 X가 일종의 Y"및 "개체 X가 개체 Y와 상호 작용 함"의 세 가지 종속성이 있습니다. 상속 / 다형성, 추상 기본 클래스 등 이러한 종속성에 도움이되는 많은 언어 기능이 있습니다.

위의 내용을 보면 OO 프로그램을 작성하는 데 언어 기능이 거의 필요하지 않다는 것을 알 수 있습니다. 이 기능은 훨씬 쉬워졌습니다.

위의 목표는 거꾸로 된 논리를 사용하여 달성 할 수 없습니다 : class 키워드를 사용하기 때문에 프로그램이 자동으로 모듈 식 디자인을 얻지 못합니다. 상속을 사용한다고해서 자동적으로 객체 의존성이 의미가있는 것은 아닙니다. OO 기능이있는 언어는 여전히 class TheWholeBloodyProgram"동물이 고양이를 상속합니다" 와 같은 것을 허용 합니다.

안타깝게도 좋은 객체 지향 프로그램 디자인이라는 주제는 이러한 종류의 토론에서 거의 언급되지 않습니다. 세뇌 된 프로그래머는 구문과 야프 만 볼 수 있습니다. 예를 들어 "C ++에는 기본 데이터 유형이 있으므로 C ++ 프로그램이 OO가 아닙니다"와 같은 힌트를 사용하지 않고 자신이 좋아하는 언어로 끔찍한 프로그램을 작성합니다. 프로그램 디자인.

어떤 언어가 적절한 OO 프로그램 설계를 지원할 수 있는지에 대한 질문에 답하십시오. 프로그래머가 객체 지향 디자인의 의미를 모르는 한 특정 OO 관련 기능이있는 언어를 찾는 것은 관련이 없습니다. 특정 언어가 객체 지향이라고 주장하는 프로그래머는 OO의 개념을 전체적으로 파악하지 못했을 것입니다. OO 프로그래머에게 OO 프로그램 설계 방법을 문의하십시오. 가장 먼저 언어 키워드를 고르는 것이라면 OO 디자인을 모른다고 가정 할 수 있습니다.

아마도 원시 소스 코드보다 훨씬 높은 수준의 고급 UML-ish 도구가있을 수 있습니다.이 도구는 프로그래머가 객체 지향 디자인이 좋은 프로그램 만 작성하도록 강요하지만 의심합니다. OO 프로그래밍을위한 최고의 디자인 툴은 여전히 ​​인간의 두뇌와 상식 일 가능성이 높습니다.

아니요, 공식적이거나 유용한 정의가 없으며 결코 존재하지 않습니다. 일부 사람들에게 OOP는 "범용 기본 클래스"및 "가비지 수집기와 함께 가장 적합한 참조 의미 체계를 사용해야 함"을 의미하며, 가장 관련성이 가장 낮은 구문 중 하나 인 구문에 대한 퀴즈를 얻을 수도 있습니다.

궁극적으로 먼저 "개체 란 무엇입니까?"라는 질문에 대답해야합니다. 더 좁은 생각은 무의미한 유니버설 기본 클래스에서 상속하고 자격을 얻기 위해 가비지 수집기에 불필요하게 할당되는 것을 주장합니다. 그러나 나는 훨씬 더 유용한 정의를 선호합니다. OOP의 목적은 일부 데이터와 해당 데이터를 호출 할 수있는 일부 기능을 갖는 것입니다. 그래서

• 객체는 어떤 상태를 유지하고 그 상태에 대한 기능을 제공합니다.

이 경우에도 int자격이 있습니다. 결국, 프리미티브 나 객체를 받아 들일 수있는 C ++로 템플릿 코드를 작성할 때 프리미티브가 실질적으로 다르다고 주장하기가 어려워집니다. Vector v1, v2; v1 + v2;대신에 의미있는 차이는 없습니다 int v1, v2; v1 + v2;(크 래피 초기화 의미론을 제외하고는 인정해야합니다). 또한 이것은 람다 및 그러한 것들이 상태를 포착하고 그 상태에 대한 기능을 제공 할 때 람다를 호출 할 때 객체가 될 수 있도록합니다.

다행스럽게도 상태 (주소)와 해당 상태 (함수 호출)를 보유하기 때문에 자유 함수에 대한 포인터를 객체로 분류 할 수도 있습니다. 따라서 모든 자유 함수가 실제로 전역 함수 포인터라고 말하더라도 자유 함수가 허용되어야합니다.

부정적인 예로 생각할 수 있습니다. Java는 객체가 아닌 기본 유형도 있기 때문에 순수한 객체 지향 언어가 아닙니다. 이들은 정수, 복식, 배열 등입니다. 순수한 객체 언어에서 객체의 의미는 모든 것이 가능합니다.

또한 객체 프레임 워크 내에서도 수정이 가능한 언어의 양에 대한 의문이 있습니다. Java에서는 String 또는 Class와 같은 일부 클래스에 대해 새 서브 클래스를 정의 할 수 없습니다.

순수한 언어는 무엇입니까? 생각 나는 유일한 후보자는 스몰 토크입니다.