객체지향의 사실과 오해( 조영호 )

​

 우리나라에서는 흔하지 않은 프로그래밍 개념서(?) ( 교과서 느낌이 아닌)

p130 객체지향 설계 기법

역할, 책임, 협력이 견고하고 유연한 객체지향 설계를 낳기 위한 가장 중요한 토양이라는 사실을 알게 됐을 것이다. 이제 역할, 책임, 협력의 관점에서 애플리케이션을 설계하는 유용한 세 가지 기법을 살펴보기로 하자.

1. 책임-주도 설계(Responsibility-Driven Design)

2. 디자인 패턴(Design Pattern)

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

p158  WHAT/WHO 사이클

책임-주도 설계의 핵심은 어떤 행위가 필요한지를 먼저 결정한 후에 이 행위를 수행할 객체를 결정하는 것이다. 이 과정을 흔히 WHAT/WHO 사이클 이라고 한다. WHAT/WHO 사이클이라는 용어가 의미하는 것은 객체 사이의 협력 관계를 설계하기 위해서는 먼저 '어떤 행위'를 수행할 것인지를 결정한 후에 '누가' 행위를 수행할 것인지를 결정해야 한다는 것이다. 여기서 '어떤 행위'가 바로 메시지다.

p180 지도 은유의 핵심

지도 은유의 핵심은 기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적이라는 것이다. 사람들의 요구사항은 계속 변하기 때문에 모델이 제공해야 하는 기능 역시 이에 따라 지속적으로 변할 수 밖에 없다.
따라서 기능을 중심으로 구조를 종속시키는 접근법은 범용적이지 않고 재사용이 불가능하며 변경에 취약한 모델을 낳게 된다. 이와 달리 안정적인 구조를 중심으로 기능을 종속시키는 접근법은 범용적이고 재사용 가능하며 변경에 유연하게 대처할 수 있는 모델을 만든다. 사람들에게 직접 길을 묻는 접근법은 기능에 구조를 종속시키는 방법이며 지도는 구조에 기능을 종속시키는 방법이다.

p188 도메인모델

그렇다면 우리가 은유를 통해 투영해야 하는 대상은 무엇인가? 그것은 바로 사용자가 도메인에 대해 생각하는 개념이다. 즉, 소프트웨어 객체를 창조하기 위해 우리가 은유해야 하는 대상은 바로 도메인 모델이다.

따라서 소프트웨어 객체는 그 대상이 현실적인지, 현실적이지 않은지에 상관 없이 도메인 모델을 통해 표현되는 도메인 객체들을 은유해야 한다. 이것이 도메인 모델이 중요한 이유다. 

p196 앨리스터 코오번의 유스케이스

p225 참고

MenuItem 의 인터페이스를 구성하는 오퍼레이션들을 MenuItem을 구현하는 단계에 와서야 식별했다는 점을 눈여겨보기 바란다. 이것은 부끄러워해야 할 일이 아니다. 인터페이스는 객체가 다른 객체와 직접적으로 상호작용하는 통로다. 인터페이스를 통해 실제로 상호작용을 해보지 않은 채 인터페이스의 모습을 정확하게 예측하는 것은 블가능에 가깝다.

설계를 간단히 끝내고 최대한 빨리 구현에 돌입하라. 머릿속에 객체의 협력 구조가 번뜩인다면 그대로 코드를 구현하기 시작하라. 설계가 제대로 그려지지 않는다면 고민하지 말고 실제로 코드를 작성해가면서 협력의 전체적인 밑그림을 그려보라. 테스트-주도 설계로 코드를 구현하는 사람들이 하는 작업이 바로 이것이다. 그들은 테스트 코드를 작성해 가면서 협력을 설계한다.

p234 다중분류

대부분의 객체지향 프로그래밍 언어들은 단일 분류만을 지원한다. 대부분의 언어에서 한 객체는 오직 한 클래스의 인스턴스여야만 하며 동시에 두 개의 클래스의 인스턴스일수는 없다. 이 관점에서 다중 분류를 다중 상속과 혼돈해서는 안된다. 다중 상속은 하나의 타입이 다수의 슈퍼타입을 가질 수 있도록 허용하지만 타입 정의를 생략할 수는 없다. 반면 다중 분류는 특정한 타입을 정의하지 않고도 하나의 객체가 서로 다른 타입의 인스턴스가 되도록 허용한다.