Go-like 언어에 비해 클래식 OOP의 장점

언어 디자인과 "이상적인"프로그래밍 언어에 필요한 요소에 대해 많은 생각을 해왔으며 Google의 Go를 연구하면서 일반적인 지식에 대해 의문을 갖게되었습니다.

특히, Go는 실제로 객체 지향 언어 의 구조 를 갖지 않고 객체 지향 프로그래밍의 흥미로운 이점을 모두 가지고있는 것 같습니다 . 클래스는없고 구조 만 있습니다. 클래스 / 구조 상속이없고 구조 임베딩 만 있습니다. 계층 구조, 상위 클래스, 명시 적 인터페이스 구현이 없습니다. 대신, 타입 캐스팅 규칙은 덕 타이핑과 유사한 느슨한 시스템을 기반으로합니다. 따라서 구조체가 "Reader"또는 "Request"또는 "Encoding"의 필수 요소를 구현하면이를 캐스팅하여 사용할 수 있습니다. 하나로서.

C ++ 및 Java 및 C #으로 구현 된 OOP에 대해 본질적으로 더 유능하고 유지 관리가 가능하며 Go와 같은 언어로 이동할 때 포기해야하는 강력한 기능이 있습니까? 이 새로운 패러다임이 나타내는 단순성을 얻기 위해 어떤 이점을 포기해야합니까?

편집
독자들이 지나치게 전화를 끊고 화를내는 것처럼 보이는 "사용되지 않는"질문을 제거했습니다.

문제는 일반적인 언어 구현에서 자주 볼 수있는 전통적인 객체 지향 패러다임 (계층 구조 등)이이 단순한 모델에서는 쉽게 수행 할 수없는 것을 제공해야하는 것입니다. 즉, 오늘날 언어를 디자인하려는 경우 클래스 계층의 개념을 포함하고 싶은 이유가 있습니까?

새로운 패러다임은 없습니다. 객체 방향은 프로그램을 작성하는 데 사용하는 패턴으로, 명확하게 정의되지 않았습니다. 다양한 언어는 객체 지향 (새로운 유형의 정의, 캡슐화, 유형 계층, 다형성, 메시지 전달 등)에 전형적인 다양한 특성을 제공하지만 다른 특성을 제공하지 못할 수 있습니다. 그러한 경우, 필요한 경우 프로그래머가 에뮬레이션해야합니다.

이러한 기능을 제공하는 많은 언어는 클래스 개념과 유사하지 않습니다 (예 : Javascript 및 Common Lisp). Java와 같은 언어 (클래스 기반, 단일 상속, 인터페이스, 유형 기반 디스패치)가 제공하는 구현은 가능성 중 하나 일 뿐이며 반드시 최상의 것은 아닙니다.

이 새로운 패러다임이 나타내는 단순성을 얻기 위해 어떤 이점을 포기해야합니까?

구조적 유형 시스템의 유형 확인은 단순히 기본 클래스가 상속 목록에 있는지 확인하는 것보다 훨씬 복잡합니다. 가상 디스패치는 약간 까다로워지고 성능이 떨어질 수 있습니다.

그러한 시스템이 OOP의 개념을 쓸모 없습니까?

아닙니다. 명령어 목록, 선언 된 규칙 세트 또는 계단식 일련의 함수가 아닌 '작업을 수행하는 객체'라는 관점에서 프로그램을 만들 수 있다면 구현은 중요하지 않습니다. 마찬가지로 형식 시스템을 변경해도 일반적인 OO 원칙은 무효화되지 않습니다.

여전히 기본 유형으로 작업 할 수 있으며 실제 유형은 신경 쓰지 않아도됩니다. 유형을 수정하지 않고 확장 할 수 있습니다. 여전히 유형이 한 가지 작업 만 수행하도록 할 수 있습니다. 여전히 세분화 된 인터페이스를 제공 할 수 있습니다. 여전히 타입에 추상화를 제공 할 수 있습니다.

어떻게 언어가 있습니다 그건 정말 중요하지 않습니다.

OOP에 대한 당신의 생각은 꽤 벗어난 것 같습니다.

'Object Oriented Programming'이라는 용어를 발명했으며이 {Java and C ++}는 내가 생각한 것이 아닙니다.
- 앨런 케이 (Alan Kay) .

타이핑 (명목 서브 타이핑, 구조적 서브 타이핑 또는 덕 타이핑 또는 이들의 조합)의 선택은 OOP와 거의 직교합니다. 상속과 클래스는 OOP와 완전히 직교합니다. 당신이 io 를 가지고 노는 데 시간이 걸리면 그것을 보게 될 것입니다.

이제 어떤 유형의 시스템이 "더 나은"지, 어떤 코드 재사용 및 조합 수단인지 물어볼 수 있습니다. 그리고 Simula (및 나중에 C ++, Java 및 C #에서 수행)와 Go (고)에서 이루어진 선택 사이의 장단점을 결정하십시오. 그러나 이것들은 모두 다르고 뚜렷한 질문입니다.

궁극적으로 OOP는 매우 모호한 개념이며이를 구현하려는 모든 시도는 매우 다양한 맛으로 나옵니다. 그러나 실제로 작업을 단순화하기 위해 OOP의 핵심 아이디어는 SOLID 하위 시스템을 구성하는 것입니다 . 이제 이것은 다른 패러다임에 대한 선을 흐리게하지만, 최근에 다중 패러다임 언어의 인기가 높아진 이유와 Google이 Go를 사용하여 자체적으로 촬영 한 이유라고 추측합니다.

OOP는 더 이상 사용되지 않습니다.

Andrea가 말했듯이 클래스에 대한 대안으로 제안 된 많은 개념이 있습니다 (예 : haskell typeclass). OOP는 한 가지 큰 이점이 있습니다. 많은 곳에서 가르치고 OOP의 문화는 개발자들 사이에서 크게 공유됩니다.

이것은 팀 내에서보다 풍부한 커뮤니케이션을 가능하게합니다. 하나는 Zygohistomorphic prepromorphism 보다 공장 에 대해 더 쉽게 이야기 할 수 있습니다 . OOP는 일반적으로 사용되는 다이어그램으로 프로그램을 구성하고 의사 소통하는 방식을 구성합니다. 이것은 강력한 자산입니다.

아니요, 여기에는 새로운 것이 없으며 OOP가 더 이상 사용되지 않습니다. C ++에는 템플릿 형식의 암시 적 인터페이스도 있지만 사람들은 여전히 ​​가상 함수를 사용합니다. 바이너리 인터페이스 또는 컴파일 타임에 다른 코드를 알지 못하는 인터페이스와 같은 명시적인 인터페이스가 필요합니다.

당신은 이것이 단순히 추론의 대명사라고 주장 할 수 있는데, 이것은 "새로운 패러다임"과 같지 않으며 더 편리합니다.