실제 실제 객체를 참조하지 않고 어떻게 OO를 가르 칠 수 있습니까? [닫은]

OO의 기본 개념은 데이터의 상태를 보호하는 방식으로 여러 시스템 간의 데이터 메시징을 처리하기위한 더 나은 아키텍처를 찾는 것이 었습니다. 아마도 그것은 나쁜 역설일지도 모르지만 (Bike, Car, Person 등) 객체 유추없이 OO를 가르치는 방법이 있는지 궁금해하고 대신 메시징 측면에 중점을 둡니다. 기사, 링크, 서적 등이 있다면 도움이 될 것입니다.

OO의 원래 개념은 오늘날의 OO와 관련이 없습니다. ( Alan Kay가 "객체 지향"이라는 용어로 실제로 무엇을 의미 했는가? 참조 ) 오늘날의 객체 지향 프로그래밍은 자전거와 주택 및 사람들의 은유와 같은 객체를 만드는 것에 관한 것입니다. 나는 은유의 목적이 사람들이 이미 이해하고있는 개념을 사용하여 이해하도록 돕는 것이기 때문에이를 고수하는 것이 좋습니다. 그들이 상관 관계를 보도록 도와주고 OO에 대해 더 깊이 이해하기 위해 차이점을 이해하도록 도와주십시오.

편집 : 오늘의 OO는 다양한 방법 (함수) 및 속성 (AKA 변수 및 상수 참조)을 사용하여 속성 및 기능이 완전히 / 부분적으로 설명되는 완전히 자체 포함 된 객체를 만드는 것입니다.

결합과 응집의 개념에 대해 이야기 할 수 있습니다. 객체는 응집력이 높고 암시 적으로 높은 결합을 갖는 속성과 방법으로 구성되어야합니다. 시스템 작동에 필요한 최소 단위 작업 및 속성에 매핑해야합니다. 또한 유지 관리 및 확장 성을 염두에두고 코딩하는 코드를 가능한 작고 간단하게 유지하려는 요구를 충족시켜야합니다.

이것은 또한 "객체 폭발", 과잉 일반화 및 모든 은유 인 잘못된 은유 선택을 방지합니다.

나는 실제 객체에 중점을 두지 않았으며 메시징에도 중점을 두지 않았습니다. 내가 사용한 예는 그래픽으로, "자신을 그리는 방법을 알고있는"객체를 원합니다.

예를 들어, OO가 내장되어 있지 않은 C에서 작업하는 경우 데이터 객체 내부의 함수에 대한 포인터를 저장하는 것이 편리하다는 것을 알 수 있습니다. 그렇다면 OOP에 푹 빠져 있습니다.

앨런 케이가 마치 모세가 태블릿을 넘기는 것처럼 말하는 것을 좋아하지 않습니다. 오히려 그는 수학과 바이오 교육을 받았다고 생각합니다. 수학자는 아마도 하드웨어와 관련이없는 추상적 인 Lambda Calculus에 대해 잘 알고있을 것입니다. LC에서는 모든 것이 "개체"라고 말할 수 있습니다. 숫자 0과 숫자 1은 인수가 주어지면 다른 것으로 평가되는 개체입니다. 스몰 토크가 꽤 멋지게 이어집니다. "메시지"의 개념은 하드웨어에 대한 이야기를 피할 수 있도록하는 것입니다. 함수 (또는 객체의 메소드)를 호출하면 메시지를 보내고 있다고 말할 수 있으며 반환되면 메시지를 사용자 (또는 연속)에게 보냅니다. 별도의 하드웨어에서 비동기 적으로 실행되는 프로그램간에 통신하는 방법을 설명하는 방식으로 고정되었습니다. 괜찮아, 그러나 일반적인 프로그래밍의 경우에는 없어지고 있습니다. OOP 아이디어의 가치를 얻기 위해 수행하려는 구체적인 작업의 관련성을 거부하거나 실행중인 하드웨어의 구체성을 거부 할 필요는 없습니다. 유능한 유추 측면에서 OOP에 대해 가르치면 사람들이 데이터 구조 측면에서 소프트웨어 설계에 대해 너무 많이 생각하게되어 과도한 설계로 이어지고 코드 부풀림과 막대한 성능 문제가 발생하여 정리할 때 시간을 소비해야합니다. 그것은 충분히 나 빠진다.

예를 들어 물리적 객체를 사용하는 것과 비 물리적 객체를 사용하는 것은 약간의 차이가 있다고 주장합니다. 코드에서 둘 다 정확히 같은 부분을 가지고 있습니다. 그래픽 예제를 사용하고 구체, 입방체, 실린더로 가르치면 공, 상자, 극을 사용하는 것과 거의 같습니다.

그래서 실제 예제를 사용하지 않고 그것을 가르치기 위해 나는 전혀 예제를 사용하지 말 것을 제안하지만, 당신이 왜 실제 예제를 원하지 않는지 알지 못하므로 주제에 대한 나의 입장은

아니, 당신은 실제 현실 세계 객체없이 그것을 가르쳐서는 안됩니다

나는 당신이 실제 은유로 시작 하는 것을 피할 수있는 방법을 알지 못하지만 거기 에 머물고 싶지 않습니다 . OOP를 올바르게 수행하면 빠르게 추상적이되지만 다음 수준의 이해에서 학습자는 객체를 객체로 이해해야합니다.

흥미롭게도 내가 좋아하는 예 중 일부는 물리적 인 대상이 아닙니다. 은행 계좌를 예로 들어 보겠습니다. deposit () 및 withdraw ()는 잔액의 가치를 변경하고 서비스 요금을 지불하는 것을 기억하기 위해 코드를 호출하는 대신 서비스 요금을 청구해야하는 이유를 모두 "얻습니다". 화면상의 모양은 이중으로 무형적이며 Stroustrup은 40 년 전으로 거슬러 올라가는 가장 오래된 두 가지 OO 사례 중 하나 인 고전적인 "도형"예제를 들었습니다.

중요한 것은 사람들이 귀하의 예를 바로 이해한다는 것입니다. 엘리베이터는 엘리베이터에 익숙한 사람들에게만 좋은 모범이됩니다. 기타.

만약 당신이 프로그래밍 그룹에 있다면 몇 사람을 모아서 시스템이해야 할 일을 서로에게 지시하는 방법에 대해 토론하기 시작하십시오. 말 그대로 시스템에서 역할을 수행하십시오 (각 역할을 수행하여 스스로 할 수는 있지만 그룹 사람들에게는 더 쉽습니다. 장난감은 혼자서 도움이됩니다). 자신의 데이터가 아닌 각 사람이하고있는 일 / 할 일에 집중하십시오. 사람들과 함께이 작업을 수행하면 메시지와 역할에 집중하는 데 도움이됩니다. 사람들은 자신이하는 일을 기억하지만 자신이 가진 데이터는 기억하지 않기 때문입니다.

서로에게 무엇을 요구하고 무엇을해야하는지 기록해 두십시오. 다른 프로그래머가 데이터에 '아니요'라고 말하고 데이터가 필요한 이유를 물으면 데이터를 보호하십시오 (데이터 캡슐화에 도움이 됨).

상향식 / 금속 방식이 유용 할 것 같습니다. 먼저 C 스타일 구조체와 포인터를 설명하여 프리미티브를 직접 사용하지 않고 데이터를 구성하는 방법을 보여줍니다. 그런 다음 후기 바인딩 및 함수 포인터를 설명하십시오. 그런 다음 이것들을 사용하여 객체를 빌드 할 수 있다고 설명하십시오. 기본적으로 잘 캡슐화 된 데이터 더미이며 해당 데이터에서 작동하는 데 필요한 함수에 대한 포인터입니다.

이 설명은 구현과 독립적으로 개념을 가르치는 기존의 수학 / 컴포지션 방식과 모순되지만, 필자가 (컴포지션, 배경이 아닌 공학을 가진 사람) 최종적으로 OO를 얻었던 관점입니다.