[2019.02.20] 객체지향의 사실과 오해 (5~6장)

5장

자율적인 객체 = 스스로 정한 원칙으로 행동하는 객체

객체가 행동하는 이유 = 다른 객체로부터 요청을 수신받았기때문

객체 B가 객체 A에게 목표 A를 수행하기 위해 행동 A를 하라고 하는 것은 자연스럽다.

객체 B가 객체 A에게 목표 A를 수행하기 위해 행동 a,b,c,d를 순차 수행하라고 하는 것은 부자연스럽다.

이 경우 객체 A는 목표 A를 위해 행동하는 것이 자유롭지 못하고 객체 B에 의존적이다.

메시지가 추상적이면 안된다.

메시지는 어떻게가 아니라 무엇을 해야하는지 설명해야한다. (어떻게 = a,b,c,d, 무엇을 = A)

메시지를 명시할 때 어떻게 수행될 지에대해 명시할 필요가 없다. 무엇이 실행되는지를 명시한다.

다형성

= 동일한 메시지에 다르게 반응하는 것

= 대체 가능성

= 재사용 가능성

= 확장이 가능해다.

= 결합도를 낮춘다

= 설계가 유연해진다.

-> 수신자의 종류를 캡슐화

= 응집도가 높아진다.

결합도를 낮추고 응집도를 높이는 것이 객체지향의 목표다.

시스템의 행위 = 객체들의 조합으로 창발

객체 지향의 강력함은 클래스가 아니라 객체들이 주고받는 메시지로 부터 발생한다.

데이터 중심으로 객체를 설계하면 데이터가 객체 정의의 일부가 되기 때문에 자율성이 떨어진다.

메시지 중심으로 객체를 설계해서 데이터를 감춰야한다.

데이터를 결정하는 것을 뒤로 미루고 행위에 집중하기 위한 것이 TDD다.

메시지를 먼저 결정함으로서 객체 인터페이스를 발견할 수 있다.

인터페이스 : 자동차 사용법을 알면 어떤 자동차 던지간에 자동차의 내부 구조를 알 필요없이 이용할 수 있도록 하는 것

공용 인터페이스 = public 

내부 인터페이스 = private = 구현

- 추상적인 인터페이스

- 최소 인터페이스

- 외부와 내부를 엄격히 분리하는 인터페이스

책임을 자율적으로 만들어라

개인적인 생각

사람이라는 객체를 만들어봐라. 일단 person 이라는 class를 만들고 age, gender, name 을 넣어서 만들면 되겠다.라고 생각하는게 데이터 중심으로 객체를 설계하는 방식이다. 저자는 이런 방식을 기피하라고 말한다. 애초에 '사람이라는 객체를 만들어봐라'라는 이 질문 자체가 틀렸다. 이 질문만으로 사람이라는 객체가 무엇을 할 줄 어떻게 아는가. '학생을 가르치는 사람이라는 객체를 만들어봐라.' 라고 질문하면 좀 더 문제가 구체화된다. 학생을 가르치는 사람은 teacher이니까 teacher라고 class를 만들 수 있다. 그리고 teach 라는 행위가 있으면 좋겠다. teacher 라는 class 에게 age, gender 와 같은 변수는 데이터는 필요없다. teach라는 행위만을 봐도 class가 어떤 역할인지 이해할 수 있다. 마구잡이 설계를 하지마라. 객체가 어떤 역할인지 고민하고 어떤 행위인지 고민해라. 그리고 이것을 도와줄 수 있는 것이 TDD다.

---

6장

요구사항은 계속 바뀐다. 모델이 제공해야하는 기능은 변할 수 밖에 없다. 기능 중심으로 구조를 종속시키면 재사용이 불가능해진다. 구조에 기능을 종속시켜라. 변경의 여지를 두는 가장 좋은 방법은 안정적인 구조를 중심으로 설계하는 것이다.

기능 수집 표현 기법 : usecase modeling

구조 수집 표현 기법 : domain modeling

domain : 사용자가 프로그램을 사용하는 대상 분야

mental model : 사람들이 사물의 상호작용을 인지하는 모형

domain model : 소프트웨어에대한 mental model

domain model

= 비즈니스가 없어지거나 완전히 개편되지 않는 한 남아있는 개념의 집합

= 로직이 추가되도 클래스와 클래스간의 관계가 그대로 유지 되는 핵심적인 부분(개념, 관계)을 찾는 것 

=> 사람들과 멘탈 모델을 공유하여 의사소통에 문제 없도록 하기 위함이다.

=> 이를 기반으로 설계와 코드를 만들면 변경에 쉽게 대처할 수 있다.

핵심적이고 단순화한 모델을 만들어라. 

이를 통해 비즈니스의 개념과 정책을 반영하는 안정적인 구조를 생각해라.

사용자와 시스템간의 상호 작용 흐름을 정리한 것을 usecase model 이라고 한다.

= 사용자들의 목표 중심으로 시스템의 기능적 요구사항을 이야기 형식으로 묶는 것

Usecase diagram에 노력을 쏟지마라

Usecase 에 담겨있는 이야기에 신경써라.

Usecase 는 여러 시나리오의 집합이다.

Usecase 는 단순 피쳐와는 다르다.

Usecase 는 자주 변경되는 사용자 인터페이스는 배제한다.

본질적인 Usecase에 집중하라.

Usecase 의 목적은 객체의 구조나 책임을 쉽게 추출하는 것이 아니다.

Usecase 를 원하는 객체의 구조나 책임으로 변환하는 것은 순수하게 다른 일이다.

Usecase 는 기능 구현을 위한 사용자 명세이며, 약간의 영감만 줄 뿐이다.

사용자가 바라보는 시스템의 외부 관점만 주목한다.

내부 구조는 가린다.

Usecase modeling : 사용자의 기능 명세

Domain modeling : 안정적인 상호 작용 명세

학교에서 배웠던 다이어그램들의 목적 : 좀 더 본질에 가까운 목표를 찾아서 안정적인 구조를 찾아내려는 시도

메시지 연쇄 = 재귀적 합성

표현적 차이	소프트웨어 객체와 현실객체의 차이
연결 완전성	모델에서 코드로의 매끄러운 흐름
가역성	코드에서 모델로의 매끄러운 흐름

객체지향 프로그래밍 패러다임이 된 이유 : 연결완전성과 가역성을 둘다 만족하기 때문