많은 오리 유형 동적 프로그래밍 언어가 프로토 타입 기반 OOP 대신 클래스 기반 접근 방식을 사용하는 이유는 무엇입니까?

많은 동적 프로그래밍 언어가 오리 타이핑 기능을 가지고 있기 때문에 언제라도 루비 나 파이썬 과 같은 클래스 나 인스턴스 메소드를 열고 수정할 수 있습니다 .

질문 1) 역동적 인 언어로 수업이 필요합니까? 왜 언어가 클래스를 프로토 타입 방식 대신 일종의 "템플릿"으로 사용하고 객체 만 사용하도록 설계 되었습니까?

또한 JavaScript 는 프로토 타입 기반이지만 CoffeeScript (향상된 JavaScript 버전)는 클래스 기반 방식을 선택합니다. 그리고 그것은에 대해 동일한가는 루아 (프로토 타입 기반) 및 MoonScript (클래스 기반). 또한 ES 6에는 수업이 있습니다.

질문 2) 프로토 타입 기반 언어를 개선하려고 할 때 무엇보다도 클래스 기반 언어로 변경해야한다고 제안하고 있습니까? 그렇지 않다면 왜 그렇게 설계 되었습니까?

질문 1) 역동적 인 언어로 수업이 필요합니까? 왜 언어가 프로토 타입 방식이 아닌 객체를 일종의 "템플릿"으로 사용하도록 설계 되었는가?

최초의 OO 언어 ( "OO"로 불리지 않았음에도 불구하고) Simula는 상속이 없었습니다. 상속은 Simula-67에 추가되었으며 클래스를 기반으로합니다.

같은시기에 Alan Kay는 새로운 프로그래밍 패러다임에 대한 아이디어를 작업하기 시작했으며 나중에이를 "개체 지향"이라고 불렀습니다. 그는 상속을 정말로 좋아했고 그것을 자신의 언어로 갖고 싶었지만 수업을 싫어했습니다. 그러나 그는 클래스없이 상속을받을 수있는 방법을 찾을 수 없었기 때문에, 그는 상속을 좋아하는 것보다 클래스를 싫어한다고 결정했으며 클래스가없는 상속과 상속이없는 Smalltalk, Smalltalk-72의 첫 번째 버전을 디자인했습니다.

몇 달 후, Dan Ingalls는 클래스 자체가 객체, 즉 메타 클래스 인스턴스 인 클래스 디자인을 고안했습니다. Alan Kay는이 디자인이 이전 디자인보다 약간 덜 어필 할 수 있다는 것을 알았습니다. 따라서 Smalltalk-74는 클래스와 클래스를 기반으로하는 상속으로 디자인되었습니다.

스몰 토크 -74 이후 Alan Kay는 스몰 토크가 잘못된 방향으로 움직이고 있다는 사실을 느꼈고 실제로 OO가 무엇을 의미하는지 나타내지 않았으며, 팀이 스몰 토크를 포기하고 신선하게 시작하겠다고 제안했지만 외향적이었다. 따라서 스몰 토크 -76, 스몰 토크 -80 (연구자에게 공개 될 첫 번째 버전의 스몰 토크), 그리고 마지막으로 스몰 토크 -80 V2.0 (상업용으로 출시 된 첫 번째 버전, ANSI 스몰 토크의 기반이 된 버전)을 따랐습니다. .

Simula-67과 Smalltalk-80은 모든 OO 언어의 조부모로 간주되기 때문에 거의 모든 언어가 클래스를 기반으로 클래스 디자인과 상속을 맹목적으로 복사했습니다. 몇 년 후, 클래스 대신에 믹스 인을 기반으로하는 상속과 표면에 기반을 둔 클래스를 기반으로하는 상속 대신에 객체를 기반으로하는 위임과 같은 다른 아이디어는 이미 너무 강해졌습니다.

흥미롭게도 Alan Kay의 현재 언어는 프로토 타입 위임을 기반으로합니다.

많은 프로그래머들이 수업을 선호합니다. 이해하기 쉬운 개념으로 세계에 대한 인간의 사고 과정의 좋은 모델입니다. 즉, 실제 객체를 우리가 속한 것으로 간주되는 추상 항목 그룹과 본능적으로 관련시킵니다. 이는 클래스입니다. . 또한 클래스는 객체 유형에 대한 추론을 더 쉽게 만듭니다. 클래스 기반 언어에서는 Liskov 대체 와 같은 원리를 적용 하는 것이 다른 방법을 가지고 있거나 런타임에 유형이 변경 될 수있는 객체가있는 언어보다 간단합니다. JavaScript에서와 같이

JavaScript에서도 수많은 코드가 단순히 프로토 타입 기능을 사용하여 클래스를 에뮬레이트합니다. 많은 프로그래머들이 그렇게 생각하는 것을 선호하기 때문입니다.

클래스 기반 언어가 선호되는 또 다른 이유도 있습니다. 효율적인 코드로 컴파일하기가 더 쉽습니다. 가장 효율적인 JavaScript VM은 메서드와 프로토 타입이 변경 될 때 JavaScript 객체 유형을 나타내는 클래스를 효과적으로 동적으로 생성합니다. 이것이 수행 된 이유에 대한 이론적 근거 는 V8 구현에 대한 이 설명을 참조하십시오 .

팀원들이 같은 코드로 공동 작업하는 대규모 프로젝트에서 유연한 언어 (런타임 동안 객체의 속성과 메서드를 수정할 수있는)는 다른 팀원이 원하지 않는 자유라고 들었습니다. 가지고 있습니다.

그들은 물건을 다룰 때 그 물건이 청사진이 말한 것처럼 행동 할 것이며 다른 야심 찬 개발자가 자신의 임무를 완수하기 위해 그것을 바꾸기로 결정한 변형 된 방식이 아니라는 것을 알고 싶어합니다.

따라서 내가 생각할 수있는 유일한 이유는 누군가이 멋진 동적 언어가 제공하는 유연성을 원하지 않을 것입니다. 팀 개발, 디버깅 및 자동 문서화를 단순화하고 싶어하기 때문입니다.

개인적으로 두 가지 방법 모두에서 응용 프로그램을 개발했으며 동적 언어를 사용하여 더 빠르게 작업을 수행합니다. 동적 언어를 다시 클래스 기반 언어로 다시 설정하도록 설계된 이러한 프레임 워크를 사용하지 않습니다. 그런 것들이 내 취향에 대한 회귀입니다.

나에게 OOP는 메시징, 로컬 보존 및 상태 프로세스 숨기기 및 모든 것의 극단적 인 구속력을 의미합니다-Alan Kay

그가 여기서 말하는 것은 OO가 메시지에 응답하는 블랙 박스를 만드는 것입니다. 어떤 식으로 REST는 동사 (예 : 메시지)와 자원 (예 : 일부 데이터를 포함하는 불투명 한 상자)을 사용한다는 점에서 최고의 OO 시스템입니다.

따라서 왜 일부는 클래스 기반이고 다른 일부는 프로토 타입 기반인지에 대한 질문은 실제로 중요하지 않다는 점을 놓치게됩니다. 둘 다 단순한 구현입니다. 메소드 호출 대신 메시징 만 사용하는 시스템은 언급 한 두 인스턴스와 마찬가지로 OO입니다.