아직 언급되지 않은 몇 가지 요소가 있다고 생각합니다.

우선 모든 것이 대상인 “순수한 OOP”(예 : 스몰 토크)에서 숫자를 하나의 지능적인 대상으로 생각하기 위해 마음을 다소 부 자연스러운 구성으로 바꿔야합니다. 실제로는 가치 일 뿐이므로 21실제로 는 가치 일뿐입니다. 이는 OOP의 큰 장점이 현실을 더욱 밀접하게 모델링한다고 들었을 때 특히 문제가됩니다. 현실.

둘째, OOP의 상속은 대부분의 사람들의 정신 모델을 따르지 않습니다. 대부분의 사람들에게 가장 구체적으로 분류하는 것은 작동하는 클래스 계층을 만드는 데 필요한 절대 규칙에 가까운 곳 이 없습니다 . 특히, class D다른 class B것을 상속받는 것을 만드는 것은 class D공유 객체가의 모든 특성을 긍정적 으로 공유 한다는 것을 의미합니다 class B. class D새롭고 다양한 특성을 추가 할 수 있지만 모든 특성은 class B그대로 유지해야합니다.

반면에 사람들이 사물을 정신적으로 분류 할 때는 일반적으로 훨씬 느슨한 모델을 따릅니다. 예를 들어, 사람이 객체 클래스를 구성하는 것에 대한 규칙을 만들면 다른 규칙을 충분히 따르는 한 거의 모든 규칙을 위반할 수 있습니다. 실제로 깨질 수없는 몇 가지 규칙조차도 거의 항상 “스트레치”될 수 있습니다.

예를 들어, “car”를 클래스로 고려하십시오. 그것은 있는지 아주 쉽게 광대 한 대부분의 사람들은 “차”로 생각하는 것의 대부분은 네 개의 바퀴가 있습니다. 그러나 대부분의 사람들은 바퀴가 3 개인 자동차를 보았습니다 (적어도 그림). 올바른 나이의 우리 중 몇몇은 또한 6 개의 바퀴가 달린 80 년대 초반의 경주 용 자동차를 기억합니다. 이것은 기본적으로 우리에게 세 가지 선택을 남깁니다.

1. 자동차에 몇 개의 바퀴가 있는지에 대해서는 아무 것도 주장하지 마십시오. 그러나 이것은 항상 4가 될 것이라는 암시 적 가정과 다른 숫자로 인해 깨질 수있는 코드로 이어질 수 있습니다.
2. 모든 자동차에는 4 개의 바퀴가 있으며, 실제로는 알고 있지만 다른 자동차를 “차가 아닌”것으로 분류하십시오.
3. 만일의 경우에도이 기능이 절대로 필요하지 않거나, 사용되거나, 제대로 테스트되지 않을 경우를 대비하여, 휠 수의 변화를 허용하도록 클래스를 설계하십시오.

OOP에 대한 교육은 종종 거대한 분류 체계를 구축하는 데 중점을 둡니다. 예를 들어 지구상의 모든 알려진 생명체의 거대한 계층 구조 또는 그 순서에 대한 거대한 계층 구조의 조각과 조각. 이로 인해 두 가지 문제가 발생합니다. 무엇보다 많은 사람들이 당면한 질문과 전혀 관련이없는 방대한 양의 정보에 집중하는 경향이 있습니다. 어느 시점에서 나는 개 품종을 모델링하는 방법과 (예를 들어) “미니어처 푸들”이 “풀 사이즈 푸들”에서 상속되어야하는지 또는 그 반대인지, 추상적 기반 “푸들”이 있어야하는지에 대해 다소 긴 토론을 보았습니다. “클래스 푸들”과 “미니어처 푸들”이 모두 포함 된 클래스. 그들이 모두 무시한 것처럼 보이는 것은 응용 프로그램이 개에 대한 라이센스를 추적해야한다는 것입니다.

둘째, 그리고 가장 중요한 것은 현재 작업에 중요한 특성에 중점을 두지 않고 항목의 특성에 중점을 둡니다. 실제로 필요한 부분을 모델링하는 데 중점을두고 있으며, 실제로 필요한 부분은 우리의 요구를 충족시킬 가장 간단한 모델을 구축하고 추상화를 사용하여 필요한 하위 클래스에 맞게 생성하여 추상화에 맞 춥니 다.

마지막으로 다시 한 번 말씀 드리겠습니다. 우리는 수년에 걸쳐 데이터베이스와 동일한 경로를 천천히 따르고 있습니다. 초기 데이터베이스는 계층 적 모델을 따랐습니다. 데이터에만 초점을 맞추는 것 외에 이것은 단일 상속입니다. 짧은 시간 동안, 몇 개의 데이터베이스가 네트워크 모델을 따랐습니다. 본질적으로 다중 상속과 동일합니다 (이 각도에서 볼 때, 여러 인터페이스는 여러 기본 클래스와 충분히 다르거 나주의를 기울여야합니다).

그러나 오래 전에 데이터베이스는 대부분 관계형 모델에 수렴되었습니다 (그리고 SQL이 아니더라도이 추상화 수준에서 현재 “NoSQL”데이터베이스도 관계형입니다). 관계형 모델의 장점은 여기서 반복하지 않을 것이라는 충분히 잘 알려져 있습니다. 우리가 프로그래밍 할 때 가장 가까운 관계형 모델의 아날로그는 일반 프로그래밍입니다 (죄송하지만 이름에도 불구하고 Java generics는 예를 들어 실제로 작은 단계이지만 자격이 없습니다) 올바른 방향으로).

답변

// The way most people think.
Operation - object - parameters
// Example:
Turn the car left.

// The way OOP works conceptually
Object - operation - parameters
// Example:
Car.Turn(270);