상속, 캡슐화 및 다형성이 OOP의 기둥이 아닌 이유는 무엇입니까? [닫은]

어느 날 나는 스택 오버플로 채팅에 갔고, 상속, 캡슐화 및 다형성이 OOP의 기둥이라는 것을 나타내는 문구를 보았습니다.

또한 비슷한 질문이 있는데, 대학 시험과 면접에서 매우 자주 질문을 받았으며 정답은 항상 질문 제목에 명시된 진술이었습니다 ( "예, 상속, 캡슐화 및 다형성은 OOP의 기둥입니다" ).

그러나 스택 오버플로 채팅에서 나는 심각하게 조롱을 당했으며 참가자들은 그러한 진술에 강력히 동의하지 않았습니다. 이 진술에 어떤 문제가 있습니까?

프로그래머가 포스트 소비에트 대학과 미국 대학에서 다른 것들에 대해 훈련 된 것처럼 보입니까?

상속, 캡슐화 및 다형성은 미국 / 영국 프로그래머가 OOP의 기둥으로 간주하지 않습니까?

상속, 캡슐화 및 다형성이 미국 / 영국 프로그래머에 의해 OOP의 기둥으로 간주되지 않습니까?

그들은 많은 프로그래머들에 의해 기둥으로 간주되며 많은 대학들이 OO를 그런 식으로 가르치고 있습니다.

불행하게도, 근시안적인 견해이기도합니다.

• 상속은 OOP를 구현하는 데 사용되는 하나의 메커니즘 일 뿐이며 OOP를 수행하지 않기 위해 남용 될 수 있습니다.
• 캡슐화는 OOP가 아닌 모든 종류의 프로그래밍에 유용한 개념입니다.
• 다형성 (polymorphism)은 계산의 작동 방식을 설명하는 특성 (?)입니다. 다형성을 달성하는 방법에는 여러 가지가 있지만 모두 특정 OO가 아닙니다.

OOP는 실제로 기초가 거의 없기 때문에 매우 개념적입니다. "물건-데이터와 기능의 묶음 묶음으로 생각함으로써 프로그램 설계에 접근하십시오."

그리고 현대의 프로그램 디자인은 "순전히 OO 방식"으로 일을하는 것에 대해 열악한 견해를 취하지 만, 대부분의 숙련 된 프로그래머는 SOLID 원칙 (또는 일부 하위 집합)이 "객체 지향 프로그래밍의 기둥"에 대한 더 나은 후보자 라는 데 동의 할 것입니다 비 OOP에 잘 적용). 이러한 용어로는 전혀 작동하지 않습니다. 대신 소프트웨어 개체 (개체가 하나 인 개체), 인터페이스 (C # / 자바 등이 하나 인 개체 interface), 추상화 및 하위 유형 (상속이 하나의 형태)의 개념을 사용합니다.

tl; dr : OO없이 상속을받을 수 있고, OO없이 캡슐화 할 수 있고, OO없이 다형성을 가질 수 있으며, OO없이 한 번에 세 개를 모두 가질 수도 있습니다. 반대로, 상속없이 OO를 가질 수 있습니다. 또한 다양한 종류의 캡슐화 (ADT 지향 및 OO)가 있지만 모든 캡슐화가 OO는 아닙니다.

긴 버전 :

"객체 지향 프로그래밍"이라는 용어는 Alan Kay가 발명 한 것이므로 그 의미를 결정하게됩니다. 그리고 그는 이것을 다음 과 같이 정의합니다 .

나에게 OOP는 메시징, 로컬 보존 및 상태 프로세스 숨기기 및 모든 것의 극단적 인 바인딩을 의미합니다.

구현 현명한, 메시징은 늦은 바인딩 프로 시저 호출, 그리고 프로 시저 호출이 런타임에 바인딩하는 경우, 당신은 디자인 타임에 알 수없는 무엇을 당신이 국가의 구체적인 표현에 대한 가정을 할 수 있도록, 당신은 전화로 가고있다. 따라서 실제로 메시징에 관한 것입니다. 후기 바인딩은 메시징의 구현이며 캡슐화는 그 결과입니다.

그는 나중에 " 큰 아이디어는 '메시징' "이라고 설명하고 "개체 지향"이라는 용어가 중요하지 않은 것에 중점을두기 때문에 "메시지 지향"대신 "개체 지향"이라고 불렀습니다. ) 및 실제로 중요한 사항 (메시지)을 산만

마지막 OOPSLA에서 스몰 토크가 구문이나 클래스 라이브러리가 아니라 클래스에 대한 것이 아니라는 사실을 모든 사람들에게 상기시키기 위해 약간의 고통을 겪었다는 것을 상기시켜줍니다. 오래 전에이 주제에 대해 "개체"라는 용어를 만들어서 유감스럽게 생각합니다.

큰 아이디어는 "메시징 (messaging)"입니다. 이것이 스몰 토크 / 스 퀘이크의 핵심이되는 것입니다 (그리고 우리의 제록스 PARC 단계에서 결코 완성되지 않은 것입니다). 일본인은 "가장 중간에있는"이라는 단어가 작습니다. 아마도 가장 가까운 영어 단어는 "삽입 광고"입니다. 훌륭하고 확장 가능한 시스템을 만드는 데있어 핵심은 내부 속성과 동작이 아닌 모듈이 통신하는 방식을 디자인하는 것입니다. 인터넷을 생각하십시오. 살기 위해서는 (a) 단일 표준을 넘어서는 많은 다른 종류의 아이디어와 실현을 허용해야하고 (b) 이러한 아이디어들간에 다양한 정도의 안전한 상호 운용성을 허용해야합니다.

(물론 오늘날 대부분의 사람들은 사물에 초점을 맞추지 않고 수업에 집중합니다.

메시징은 메타와 메커니즘으로 OO의 기본 입니다.

누군가에게 메시지를 보내면 상대방이하는 일을 알 수 없습니다. 관찰 할 수 있는 유일한 것은 그들의 반응입니다. 메시지 자체를 처리했는지 (예 : 객체에 메소드가있는 경우), 메시지를 다른 사람에게 전달한 경우 (위임 / 프록시) 모르는 경우 알 수 없습니다. 그것이 캡슐화의 모든 것입니다. 그것이 OO의 모든 것입니다. 프록시는 예상 한대로 응답하는 한 실제 프록시와 구별 할 수 없습니다.

"메시징"에 대한 "현대적인"용어는 "동적 메소드 디스패치"또는 "가상 메소드 호출"이지만 은유를 잃고 메커니즘에 중점을 둡니다.

윌리엄 R. 쿡 (William R. Cook)이 재검토 한 On Understanding Data Abstraction 에서도 비슷한 점을 지적 하고 있으며 "개체"와 "개체 지향"에 대한 단순화 된 현대적 정의에 대한 그의 제안 .

작업의 동적 디스패치는 객체의 필수 특성입니다. 호출 할 조작이 오브젝트 자체의 동적 특성임을 의미합니다. 작업을 정적으로 식별 할 수 없으며 주어진 요청에 대한 응답으로 실행되는 작업을 제외하고는 어떤 작업이 실행 될지 일반적으로 알 수 없습니다. 이것은 항상 동적으로 전달되는 일급 함수와 동일합니다.

Smalltalk-72에는 아무 물체도 없었습니다! 파싱, 재 작성 및 재 라우팅 된 메시지 스트림 만 있었습니다 . 처음에는 메소드 (메시지 스트림을 구문 분석하고 다시 라우팅하는 표준 방법)가 왔으며 나중에 오브젝트 (일부 개인 상태를 공유하는 메소드 그룹)가 나왔습니다. 상속은 훨씬 후에 왔으며 클래스는 상속을 지원하는 방법으로 만 소개되었습니다. Kay의 리서치 그룹이 이미 프로토 타입에 대해 알고 있었다면 아마도 처음에는 수업을 소개하지 않았을 것입니다.

모든 프로그래머는 데이터 이해 이해, 재검토를 읽어야 합니다. 객체와 추상 데이터 유형의 차이점이 정확히 무엇인지 자세히 설명합니다. 그는 Java를 사용하여 예제를 제공 하며 ADT 예제 와 Object 예제 모두 에서 상속, 캡슐화 및 다형성을 사용하지만 예제 중 하나만 객체 지향 이기 때문에이 질문과 매우 관련이 있습니다 ! 다시 말해, 상속, 캡슐화 및 다형성을 가질 수 있으며 한 번에 세 개를 모두 가질 수 있으며 여전히 OO를 가질 수는 없습니다.

반면에 상속없이 OO를 가질 수 있습니다. 위에서 암시 한 바와 같이 : 스몰 토크의 원래 버전 ( "Object-Oriented Programming"이라는 용어를 발명 한 Alan Kay가 디자인 한 언어)에는 상속이 없었습니다.

마지막으로, 올랜도 조약은 상속에 대한 대안으로 위임 을 논의 하고, 다양한 위임과 상속이 객체 지향 언어의 디자인 공간 내에서 다른 디자인 포인트로 이어지는 방식에 대해 논의합니다. (실제로 Java와 같은 상속을 지원하는 언어에서도 사람들은 실제로 피하지 말아야한다는 사실을 기억하고 다시 OO에 필요하지 않음을 나타냅니다.)