객체 지향 프로그래밍 패러다임은 모듈식이 아니며 병렬이기 때문에 구식입니까? [닫은]

CMU의 교수 인 Robert Harper가 게시 한 신입생에게 FP를 가르치는 논란이 많은 기사를 읽었습니다 . 그는 CMU가 더 이상 입문 과정에서 객체 지향 프로그래밍을 가르치지 않을 것이라고 주장했다.

그리고 그는 주장했다.

객체 지향 프로그래밍은 본질적으로 반 모듈 식 및 반 평행이기 때문에 입문 교과 과정에서 완전히 제거됩니다.

왜 OOP를 반 모듈화 및 역 병렬로 간주합니까?

CS 교육 과정 수업에 대한 Harper의 요구 는 실제 프로젝트 의 요구와 는 매우 다릅니다 . 그의 임무는 신입생에게 기본 개념 (예 : 모듈성, 병렬성, 유도)을 가르치는 것입니다. 따라서 선택한 언어 (및 패러다임)는 가능한 한 적은 식 (구문 적 및 개념적)으로 이러한 개념을 표현할 수 있어야합니다. 이 맥락에서 친숙 함, 도구 지원, 사용 가능한 라이브러리, 실행 성능 등은 전혀 관련이 없습니다. 따라서 다음을 고려할 때이 점을 명심하십시오.

OO가 반 모듈 식이라는 견해 는 잘 설계된 클래스의 객체조차도 다른 클래스에 대한 많은 수의 종속성에서 비롯된 결과입니다. 지난 몇 년 동안 Dependency Injection 프레임 워크 , 기사, 서적 및 블로그 게시물 의 확산 을 볼 때 OO의 지지자 입장에서도 이것이 문제라는 것이 분명해졌습니다 (모의와 스텁의 증가는 흥미 롭습니다).

또 다른 힌트는 팩토리, 빌더, 어댑터, 브리지, 데코레이터, 외관, 명령, 반복자, 중재자, 관찰자, 전략 및 템플릿 방법과 같은 다른 프로그래밍 패러다임과 비교할 때 디자인 패턴 의 중요성 과 구현의 복잡성입니다. Composite은 OO 코드의 모듈성을 향상시키는 것과 관련이 있습니다.

상속도 문제가있다 (예를 들어, 깨지기 쉬운 기본 클래스 문제 )와 (하위) 다형성 유혹 한 변경은 전체 상속 체인을 통해 리플 수있는 여러 클래스 사이의 알고리즘의 구현까지 유출 (최대 및 다운!).

반 평행 의 책임은 계산과 비교하여 상태 의 강조 (일명 변경 성 대 불변성)와 관련이 있습니다. 전자는 하위 액터의 의존성 을 표현 하는 데 더 관여합니다 (하퍼가 병렬 처리를합니다!) 일반적으로 상태가 관리되는 위치 (일명 인스턴스 변수가 선언 된 파일)에서 외부 액터가 추론 할 수 없으므로 어떤 시점에서 변경됩니다.

불변성과 계산에 중점을두면 상태 관리가 없으므로 하위 계산의 종속성을 표현하려는 위치에 기능 / 계산 만 결합되므로 하위 계산의 종속성을 훨씬 쉽게 표현할 수 있습니다.

이것은 아마도 대담한 주장일지도 모르지만,이 로버트 하퍼 는 실제로 그의 인생에서 실제 소프트웨어를 쓰지 않았다고 생각합니다. 그가 관심을 갖는 것은 ML과 정적 유형 시스템뿐입니다. 가능한 한 큰 기여를한다면 OOP에 대한 그의 주장이 어떻게 관련이 있는지 알 수 없습니다.

이 기사는 논쟁의 여지가 없습니다. 논쟁은 시험, 논쟁 및 토론을 포함합니다. 당신이 여기있는 것은 어떤 무지한 학문으로, 단 하나의 진술로 두 가지 매우 근본적인 비난을 주장 할뿐입니다.

1. 안티 모듈러라는 OOP에 대한 주장은 전혀 말도 안됩니다. 난, 그것뿐만 아니라 인수가 제공되지 않았다 응답하는 방법을 모르는뿐만 아니라 디자인으로 OOP는 것입니다 캡슐화와 추상화의 수단을 통해 개별 모듈 사이의 매우 낮은 커플 링 모듈 방식을 설정하는 방법은.

2. OOP가 반 병렬이라고 주장하는 것은 이해의 부족을 보여줍니다. OOP는 동시성에 대한 결정을 내리지 않습니다. OOP는 단지 그것들을 숨기도록 지시합니다. 올바르게 구축되면 객체의 구현이 병렬인지 아닌지를 말할 수 없습니다.
   따라서 궁극적으로 OOP와 병렬 프로그래밍은 직교합니다. 액터 모델은 동시성에 대한 우아한 모델로, 오브젝트 시스템에 직접 반영 될 수 있지만 (필수는 아님) 둘 다의 강력한 조합을 생성합니다.

OOP의 문제점은 Alan Kay가 정의한 의미에서 실제로 이해하는 사람이 거의 없다는 것입니다.

1. OOP는 접근 방식입니다. 일부 언어에서는 패턴을 사용하여 구현되고 다른 언어에서는 내장 언어 관용구 (예 : Ruby, Objective-C, Smalltalk, Io )를 직접 사용할 수 있습니다 .
2. 일반적인 생각과 달리 OOP는 수업에 관한 것이 아닙니다. 그것은 객체에 관한 것이고 객체는 메시지 전달 에 관한 것입니다.

그렇기 때문에 Java는 해군 전투를 지적하는 막대기를 OOP해야합니다. 이것은 "OOP- 언어"라고 불리는 다른 많은 사람들에게도 해당되지만, Java에 대한 것은 OOP를 가르치기 위해 Java를 사용해야한다는 것이 대학에 대한 일반적인 신념 인 것 같습니다.

Java 를 사용한 OOP 소개를 CS 커리큘럼에서 제거해야 한다고 생각하는 모든 사람들에게 동의합니다 . 또한 OOP에 대한 근본적인 이해가 분명하지 않은 사람들은이를 가르치면 안된다고 생각합니다. 따라서 Bob이 자신의 과정을 위해 ML을 고수하고 단순히 자신이 이해하고있는 것을 가르치는 것이 더 좋습니다.
지금 OOP는 사람들이 모든 것을 고집하는 것을 좋아하는 세련된 에티켓에 가깝습니다. 이것은 OOP에 해를 끼치며 사람들에게 말했다. OOP는 구식이 아닙니다. OOP의 황금 시대는 아직 사람들이 그렇지 않은 것에 대한 것이 무엇인지 이해하는 시점에 아직 오지 않았습니다 (예 : 키워드를 class500 번 사용하여 가능한 모든 문제 해결 ).

당신은 모든 줄무늬의 열광자를 얻습니다.

객체 지향 프로그래밍은 총알이 아닙니다. 그것은 결코 없었다. 그것이 과대 광고의 피해자입니다. 필연적으로 사람들은 과대 광고에 시달리고 역학이 시작되기 시작합니다 (실제 패러다임의 유용성에 관계없이).

20 년이 지난 지금 우리는 함수형 프로그래밍에 대한 반발이있을 것입니다.

저자의 모호한 생각을 두 번째로 추측 할 수 있기 때문에이 질문에 완전히 대답 할 수 없습니다. 이 기사가 저자에게 당혹 스러울 것이라고 생각합니다. OOP에 대해서는 모듈 식이나 병렬식이 아님을 암시하는 것은 없습니다.

모듈성 : OOP의 주요 측면은 실제로 모듈 식이라는 것입니다 (그러나 모듈성은 서로 다른 상황에서 다른 것을 의미합니다). 따라서 저자가 일반화 또는 정적 프로그래밍에 대해 이야기하고 있는지에 관계없이 그는 잘못되었습니다.

병렬화 : 병렬 프로그래밍과 관련하여 대부분의 프레임 워크는 interupts와 threading을 지원했으며 이제는 .Net framework 4.0과 OOP 언어에서 볼 수있는 것과 같은 적절한 병렬화를 지원했습니다.

필자는 기능 프로그래밍과 OOP가 상호 배타적이라는 오해가 있다는 점에서 저자가 패션 희생자가되었다고 생각합니다. OOP 언어에는 기능적 스타일이 있으며 문서화되어 있습니다. 예를 들어 Oliver Sturm이이 영역에 게시했습니다.

저자는 신입생 프로그래머가 OOP를 이해하기가 너무 어렵다고 주장합니다. 반 모듈화 및 반 병렬 진술은 순전히 기능적인 언어와 비교할 때 좁은 맥락에서 사실 일 수 있지만, 전체 패러다임에 대한 정죄는 거의 아니다 (어떻게 그것을 사용하는지 아는 사람들에게는 잘 작동하는 것 같다).

제안 된 커리큘럼은 한 클래스의 기능 프로그래밍, 다른 클래스의 명령형 (절차) 프로그래밍 및 다른 클래스의 데이터 구조를 가르칩니다. 신입생이이 3 가지를 숙달하면 OOP를 배울 준비가됩니다.

개인적으로 나는 그것이 과잉이라고 생각하지만 학계는 새롭고 극단적 인 것을 시도하는 것을 좋아합니다. 균형을 잡기 위해 MIT는 하나의 신입생 수업에서 모든 주요 프로그래밍 패러다임을 가르쳤습니다.

이상하게도 두 학교는 정말 훌륭한 프로그래머를 배출했습니다. 그림을 이동.