OOP에 대한 필수 개념에 대한 일관된 정의가없는 이유는 무엇입니까?

나는 프로그래밍에 익숙하지 않고 다른 소스에서 다른 규칙을 읽고 듣고 약간 혼동합니다.

객체 지향 프로그래밍에는 4 개 또는 5 개의 개념이 있습니까?

새로 온 사람으로서, 나는 이것이 5 가지 개념이라는 것을 이해합니다.

• 추출
• 계승
• 캡슐화
• 다형성
• 모듈성

그렇다면 어떻게 더 "엄격한"정의를 찾지 못하고 이러한 개념들을 몇 가지 배열 한 것처럼 보이는가?

객체 지향 프로그래밍의 의미에 대해 다른 설명을 찾는 이유는 보편적으로 적용 가능한 엄격한 정의를 공식화 할 권한이있는 개인이나 조직이 없기 때문입니다.

객체 지향 프로그래밍은 ISO 표준 또는 과학적 법률이 아닙니다. 철학입니다. 모든 철학과 마찬가지로 모든 종류의 다른 해석이 있으며 보편적으로 적용 가능한 해석은 없습니다. 소프트웨어 아키텍처를 설계 할 때 따라야 할 개념을 설명하는 텍스트를 읽을 때, 이는 전문적인 경험 중에 저자가 작성한 의견을 기반으로하며 보편적 인 사실이 아니라는 지침으로 볼 수 있습니다.

객체 지향 프로그래밍에 5 개 또는 4 개의 구성 요소가 있습니까?

다른 사람들이 언급했듯이 "OO"에는 실제로 컴포넌트가 없습니다. 툴킷이나 명확하게 정의 된 프로세스가 아닌 문제에 대한 솔루션을 모델링하는 방법이기 때문입니다.

새로 온 사람으로서, 나는 이것이 5 가지 요소라는 것을 이해합니다.

추상화, 상속, 캡슐화, 다형성 및 모듈성?

상속과 다형성은 프로그래밍 언어 기능입니다. 그것의 좋은 당신은 이것들을 이해하지만 그들이 기억해 도구 (다른 도구로, 그들은 특정 문제를 해결하기 위해 사용되어야하고, 목표 또는 무언가를 향해 노력하기로 취급하지 않는 것이 수단). "OO"코드 중 하나를 사용하지 않고도 작성할 수 있습니다. 내가 본 최고의 "OO"코드 중 일부는 상속 또는 다형성을 거의 사용하지 않습니다.

추상화, 캡슐화 및 모듈성은 코드와 관련이 없으며 문제를 보는 방식, 문제를 이해하려는 방식, 코드에서 솔루션을 설계 및 구성하는 방식에 대한 것입니다.

또한 이러한 디자인 아이디어는 "OO"에만 국한되지 않습니다. 아마도 당신은 아마도 기본 수준에서 그것들을 이해했을 것입니다. 여기에는 교과서 완벽 정의를 설명하고 다소 사소한 문제에 적용 할 수있는 것이 포함될 수 있습니다. 이해에 대한 심층 테스트에는 매우 큰 복잡한 문제가 있으며 얼마나 복잡하게 처리 할 수 ​​있습니까?

이해의 또 다른 테스트는 문제를 해결하기 위해 사용하는 방법입니다. 데이터 모델링 측면에서 OO에 대해 종종 배우는 "OO"를 처음 접하는 사람들 (1990 년대에 대부분의 사람들이 그것을 이해하는 데 사용 된 방식이기 때문에)은 종종 문제의 잘못된 측면에 초점을 맞 춥니 다. 데이터에 너무 많은 영향을 미치며 행동에 충분히 집중하지 않습니다.

예를 들어, 고전적인 예는 종종 같은 엔티티를 참조 Dog, Cat, Elephant, Seagull, Shark, 등 종종 예를보고 바로 생각 "OO"신규 이민자 "아,라는 기본 개체가 필요합니다 Animal" , 그들은 심지어는 다른 끝낼 수 있습니다 각기 다른 속성을 가진 깔끔한 상속 계층 Mammal과 같은 중간 엔티티 Amphibian.

그러한 사고 방식은 여러 가지 OO 개념에 대한 매우 기본적인 이해를 보여 주지만 숙련 된 OO 프로그래머는 절대 그런 식으로 접근하거나 결론에 도달하지 않습니다 (실제로 충분한 정보가 없다고 불평합니다). OO 모델링보다는 모델링이 가능하며,이 예에서는 동물 의 행동 에 대해 아무 말도하지 않기 때문에 (오늘날 많은 사람들이 OO 의 본질 이 모두 행동과 기능에 있다고 주장 합니다).

"OO"를 배우는 길은 전통적으로 모델링하는 문제의 행동에 대해 아무것도 알지 못하거나 너무 적을 때, 또는 당신이 아닌 엔티티에주의를 집중시키는 실수를 할 때 잘못된 추상화를 작성하는 데 시간을 소비하는 것과 관련이 있습니다. 그 기능 중 일부는 수년에 걸쳐 작성된 많은 책, 코스 및 온라인 자습서가 학습자들을 오랫동안 길을 안내해 왔기 때문에 (조수가 바뀌고 있기 때문입니다).

전반적으로 많은 이해가 경험하게 될 것입니다. 지금까지 배운 개념은 좋은 출발이며, 길을 따라 배워야 할 개념이 더 많으며 (예 : "SOLID"및 "DRY"원칙), 퍼팅에 오랜 시간을 소비해야합니다. 모든 것이 제자리에 "클릭"되기 전에 실제 매우 복잡한 문제에 대한 이론.

Alan Kay 박사는 "개체 지향"이라는 용어를 사용 했으므로, 이것이 의미하는 바에 대한 권위있는 출처이며 다음과 같이 정의합니다 .

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

그것을 분해하자 :

• 메시징 (Smalltalk에 익숙하지 않은 경우 "가상 메소드 디스패치")
• 상태 프로세스는
  • 국부적으로 보유
  • 보호
  • 숨겨진
• 모든 것의 극단적 인 구속력

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

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

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

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

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

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

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

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

따라서 Alan Kay의 정의를 보는 두 가지 방법이 있습니다. 독자적으로보고있는 경우 메시징은 기본적으로 지연된 프로 시저 호출이고 지연 바인딩은 캡슐화를 의미하므로 # 1을 결론 지을 수 있습니다. # 2는 실제로 중복되며 OO는 늦게 바인딩됩니다.

그러나 나중에 중요한 것은 메시징이라는 것이 명확 해 졌으므로 다른 관점에서 볼 수 있습니다. 메시징은 지연됩니다. 이제 메시징이 유일 하게 가능하다면 # 3도 그렇습니다. 단 하나만 있고 그 것이 늦으면 모든 것이 늦습니다. 그리고 다시 한 번 캡슐화는 메시징에서 따릅니다.

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

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

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

유형 및 프로그래밍 언어의 Benjamin Pierce 는 객체 지향의 정의 기능이 Open Recursion 이라고 주장합니다 .

Alan Kay에 따르면 OO는 메시징에 관한 것입니다. William Cook에 따르면, OO는 동적 메소드 디스패치 (실제로 동일한 것)에 관한 것입니다. 벤자민 피어스 (Benjamin Pierce)에 따르면, OO는 Open Recursion에 관한 것입니다. 이는 기본적으로 자체 참조가 동적으로 해결되거나 (또는 ​​적어도 생각하는 방식 임), 즉 메시징입니다.

보시다시피, "OO"라는 용어를 만든 사람은 대상에 대해 다소 형이상학 적 관점을 가지고 있으며, Cook은 다소 실용적 관점을 가지고 있으며, 매우 엄격한 수학적 관점을 관통합니다. 그러나 중요한 것은 철학자, 실용 주의자 및 이론가가 모두 동의한다는 것입니다! 메시징은 OO의 한 축입니다. 기간.

상속에 대한 언급은 없습니다! OO에는 상속이 반드시 필요한 것은 아닙니다. 일반적으로 대부분의 OO 언어에는 구현 재사용 방법이 있지만 반드시 상속 할 필요는 없습니다. 예를 들어 어떤 형태의 위임 일 수도 있습니다. 실제로, 올랜도 조약은 위임 을 상속의 대안으로 설명 하고, 다양한 위임 및 상속 양식이 객체 지향 언어의 디자인 공간 내에서 다른 디자인 포인트로 이어지는 방식에 대해 논의합니다. (실제로 Java와 같은 상속을 지원하는 언어에서도 사람들은 실제로 그것을 피하도록 지시 받았으며 다시 OO에 필요하지 않음을 나타냅니다.)

@Philipp이 말했듯이 문제의 근본은 프로그래밍 언어를 객체 지향으로 만드는 것에 대한 공식적인 정의가 없다는 것입니다. 실제로 이것은 아마도 좋은 것입니다. OO 프로그래밍을 지원하는 방법에는 여러 가지가 있으며 각각 고유 한 장단점이 있습니다. 어떤 언어가 "순수한 OO"인지에 대한 토론은 실제로 많은 것을 이루지 못합니다.

그러나 나열된 5 가지 속성을 살펴보면 모듈성은 분명히 이상한 것입니다. 모듈성은 실제로 프로그래밍 언어가 아닌 프로그램의 속성입니다. 언어 수준에서이 속성은 "모듈화 지원"이며 일반적으로 "모듈"pr "패키지"메커니즘의 형태를 취합니다.

그러나 Modularity에 대한 나의 반대 의견은 전형적인 프로그래밍 언어 인 Smalltalk-80이 모듈을 전혀 지원하지 않는 한 OO 프로그래밍 또는 OO 프로그래밍 언어의 핵심은 아니라는 것입니다. 그리고 당신이 그것에 대해 생각할 때, 널리 사용되는 많은 OOPL에서 모듈에 대한 언어 지원은 "약합니다".

모듈은 한 사람이 완전히 이해하기에는 코드 기반이 너무 커지는 "대규모 프로그래밍"을 지원하도록 설계되었습니다. 또한 코드를 모듈화하기 위해 프로그래밍 언어의 모듈이 필요 하지 않습니다 .

^{나는 다른 4 가지 속성에 대한 토론에 참여하지도 않고, 어떤 "상속"모델이 순수한 OO인지에 대한 토론에 참여하지도 않는다. 또한 Alan Kay가 OO 프로그래밍을 발명 한 것으로 인정되지만 OO / 및 OOPL에 대한 그의 정의가 최고의 것을 의미하는 것은 아닙니다. 분명히 그렇지 않습니다. 그는입니다 권위있는 소스,하지만 (실제로는) 더 큰 무게를 가지고 있다고 OO & OOPLs에 대한 다른 정의를주고 다른 소스가있다.}