객체지향의 사실과 오해 [chpt 3,4]

- 이 글은  객체지향의 사실과 오해 리뷰를 위한 메모 글이며, 공부 목적을 위한 노트 입니다.  글은 4월 초에 완성합니다.

 

chpt 3 타입과 추상

 

리스코프 치환 원칙을 먼저 설명한다.

“서브 타입은 언제나 자신의 기반 타입(base type)으로 교체할 수 있어야 한다."

• 로버트 C. 마틴

조용호 님의 블로그 주소이다 : http://aeternum.egloos.com/

토비님의 유투브에 나온 인터뷰에서 가져왔다. : https://www.youtube.com/watch?v=8OclN9kZTE4

책은 나오는 것 까지 7년이 걸렷다고 한다,

추상화를 통해 복잡성을 극복한다.

복잡한 런던 지하철의 초기 지도는 실측을 기반으로 사용자에게 정보를 제공하였지만, 복잡했다.

오늘날의 지하철은 역간의 거리와 상관 없이 표기를 하는 해리 벡의 지하철 노선도를 사용한다.

해리 벡의 지하철은 지형 정보를 제거하고 역 사이의 연결성을 강조했다.

• 승객들이 지하철을 “바라보는” “모델” 과 일치했다. 구체적인 역의 위치가 아닌 역 간의 연결 관계에 주목했다.

승객들이 지하철을 이용하는 이유와 해리 벡이 지형 정보를 제거한 이유는 동일 했다.

추상화 : 현실을 기반으로 한 불필요한 부분을 제거한 사물의 본질을 드러나게하는 과정이다.

• 공통점 추출 , 차이점 제거 일반화를 통해 단순하게 만든다.
• 중요한 부분을 강조 , 불필요한 세부 사항을 제거 →” 원하면 주는건 어떰?”

지하철 프로그램 설계 개인 생각

• 지하철 역 : 다른 역들과 연결이 되어야함
• 지하철 : 역사이를 이동하면서 시간정보를 제공해야한다.

→ 인터페이스 잘 쓰자.

 

 

 

chpt 4 역할,책임,협력

 

 

 

개별적인 객체의 행동이나 상태가 아니라 객체들간의 협력의 집중하자.

협력

• 객체의 요청으로 시작이 된다,
• 요청과 응답은 협력에 참여하는 객체가 수행할 책임을 정의한다.

책임

• 어떤 객체에 대한 요청은 그 객체가 요청을 처리할 책임이 있음을 의미한다.
• 책임을 어떻게 구현할 것인가가 아닌, 어떻게 할당할 것인가가 핵심이다.
• 책임은 객체의 공용 인터페이스 (public interface)를 구성한다.→ 캡슐화로 이어짐
• 문맥 속에서 메시지에 대한 요청을 받은 쪽의 할 수있는 일의 나열

분류

1. 하는 것 doing
   • 객체를 생성하거나 계산을 하는 등 스스로 하는 것
   • 다른 객체의 행동을 시작시키는 것
   • 다른 객체의 활동을 제어하고 조절하는 것
2. 아는 것 knowing

• 개인적인 정보에 대해 아는 것
• 관련된 객체에 대해 아는 것
• 자신이 유도하거나 계산할 수 있는 것에 대해 아는 것

역할

• 어떤 객체가 수행하는 책임의 집합은 객체가 협력 안에서 수행하는 역할을 암시한다.
• 역할의 개념을 사용하면 유사한 협력을 추상화한다.
• 객체가 역할을 대체 가능하기 위해서는 협력 안에서 역할이 수행하는 모든 책임을 동일하게 수행할 수 있어야 한다.
• 역할의 대체 가능성은 행위 호환성을 의미하고, 행위 호환성은 동일한 책임의 수행을 의미한다.

---

---

유사한 새 개의 협력

왕 - 토끼 - 모자 장수

왕 - 토끼 - 쥐

여왕 - 토끼 - 엘리스

: 3가지 과정이 완벽하게 동일하다. 다른 점은 객체, → 하나로 관리를하자 → 재판 과정이 바뀌면 관리하기 쉽다.

추상화를 시키자 → 역할로 구분하자

“판사 - 토끼 - 증인 “ : 단순하다. 문제에 집중,

point ! 역할끼리는 메시지를 주고 받는다.

= 역할을 대체할 수 있는 객체는 동일한 메시지를 이해할 수 있는 객체로 한정한다.

증인 역할 : ex. 엘리스, 모자 장수, 쥐

→ 메시지 “증언하라 “의 일을 처리 해야함.

객체의 모양을 결정하는 협력

1. 견고하고 깔끔한 협력을 설계해야 한다. 즉, 객체들이 주고받을 요청과 응답의 흐름을 결정하여 책임을 정의해야 하는 것이다.
2. 협력이라는 문맥에서 객체가 수행하게 될 적절한 책임, 즉 행동을 결정해야 한다.
3. 객체가 행동을 수행하기 위해 필요한 데이터를 결정해야 한다.
4. 협력에 참여하기 위한 객체의 데이터와 행동이 결정된 후 클래스의 구현 방법을 결정해야 한다.

객체지향 설계 기법

책임-주도 설계 (Responsiblity-Driven Design)

• 협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당하는 방식
• 기능은 더 작은 규모의 책임으로 분할되고 각 책임은 적절한 객체에 할당된다.
• 객체는 자신의 책임 외의 것에 대해 적절한 객체를 찾아 필요한 작업을 요청한다.
• 결과적으로 요청과 응답을 통한 객체들 간의 협력 관계가 구성된다.

디자인 패턴 (Design Pattern) : present

: Optional

• 책임-주도 설계의 결과로,

→ 반복적으로 사용하는 문제해결을 위한 설계 템플릿(역할, 책임, 협력)의 모음

• 특정 상황과 문제에 공통으로 사용할 수 있기 때문에 역할과 책임, 협력 관계를 빠르고 손쉽게 포착할 수 있다.
• 상황의 맞는 해결 ,,, 틀에 맞출려고 이용할려고 하지 말자,,,, 떠올라야한다.

테스트-주도 개발 (Test-Driven Development)

• 테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 작성하는 방식
• 객체의 역할이 메시지를 수신할 때 어떤 결과를 반환하고 어떤 협력을 하는지에 대한 기대를 코드의 형태로 작성한다.
• 객체지향에 대한 깊이 있는 지식과 책임-주도 설계의 원칙에 대한 종합적인 이해가 요구되는 개발 방식이다.