객체지향의 사실과 오해

2019.01.16(수) 분명 오전에 한 챕터 읽었는데 기억이 나지 않는다.

그래서 정리 하기로 했다.

---

01. 협력하는 객체들의 공동체

"시너지를 생각하라, 전체는 부분의 합보다 크다."

클래스를 떠올리기 전에 객체를 먼저 떠올려라.

"실세계를 모방한 것이 객체지향이다."라는 용어는 객체를 설명하기 편리한 용어이나 실 세계를 반영 할 수 없다.

버트란드 마이어 : "소프트웨어 시스템이 해결하려고 하는 실제는 잘해봐야 먼 친척 밖에 되지 않는다"

-> 실 세계를 소프트웨어 반영할 때 100프로란 없다.

객체 지향이라는 용어를 사용 할 때는 소프트웨어에 실세계를 전부 반영할 수 있다는 의미보다는 객체란 '대략'적으로 세계를 반영 할 수 있는 개념으로 생각하는 편이 도움이 된다.

공동을 목적을 달성하기 위해 "협력"을 하며 협력 할 때 "메시지"를 주고 받는다.

메시지는 명시적으로 계약 한 일종의 행위이자 함수이다.

1. 커피 공화국

2019.01.16(수)

손님, 캐시어, 바리스타라는 객체가 있다.

커피를 주문부터 손님에게 전달하기까지의 목적을 위해 각각의 객체가 "역할", "책임", "협력"을 한다.

요청과 응답으로 구성 된 협력

요청 : |손님| -> (커피를 주문한다) -> |캐시어| -> (커피를 제조하라) -> |바리스타|

응답 : |바리스타| -> (커피 완성) -> |캐시어| -> (커피 완성) -> |손님|

어찌 보면 Spring MVC 패턴과 유사하다.

손님, 캐시어, 바리스타가 각각의 역할에 맞는 책임을 다하면서 협력하여 목적을 달성한다.

(객체) : 적합한 책임을 수행에 필요한 개념

1. 여러 사람이 동일한 역할을 수행할 수 있다. : A캐시어가 그만두면 꼭 A라는 캐시어를 고집하지 않아도 된다. B를 새로 채용하면 된다.

2. 역할은 대체 가능성을 의미한다. : 손님 입장에서는 A 바리스타가 만드나 B 바리스타가 만드나 개의치 않는다.

3. 책임을 수행하는 방법은 자율적으로 선택 할 수 있다 : 바리스타가 커피에 데코를 하건 안하건 자율적이다.

4. 한 사람이 동시에 여러 역할을 수행 할 수 있다. : 캐시어가 주문을 받고 커피를 만들수도 있다.

개념 정리

사람을 객체로

손님의 요청을 메시지로

요청 처리를 메서드로

메시지를 전송하는 객체를 송신자로

메시지를 수신하는 객체를 수신자로

-> 변경하면 객체 지향의 기본 개념을 설명 할 수 있는 은유적 표현이 되어 비교적 쉽게 객체 지향에 대한 설명을 할 때 "실 세계를 반영했다"라고 설명하는 이유가 될 수 있다.

객체 시민 : 자신에게 주어진 역할과 책임을 다하는 동시에 시스템의 더 큰 목적을 이루기 위해 더 큰 목적을 이루기 위해 다른 객체와도 적극적으로 협력한다.

객체의 두 가지 덕목

협력과 자율

협력 : 전지전능한 객체는 자멸하고 만다.
        적절한 역할과 책임으로 할 수 없는 부분에 대해서는 협력 할 수 있어야 한다.

자율 : 스스로의 원칙을 스스로 통제하고 절제하는 것으로 스스로 판단하고 행동한다.

객체의 상태와 행동

객체는 상태와 행동을 가지며 다른 객체가 무엇을 수행하는지는 알 수 있지만 어떻게 수행하는지는 알 수 없다.

객체의 내부와 외부를 결정짓는 접근 지시자를 의미하는 부분인것 같다.

정리

클래스는 객체를 구현하는데 필요한 메커니즘일뿐이다.

객체는 실세계를 모두 반영 할 수 없지만 실세계를 소프트웨어에 반영하는데 도움이 되는 개념이다.

객체는 역할, 책임, 협력을 기반으로 한다.

2. 이상한 나라의 앨리스

2019.01.17(목)

행동이 상태를 결정한다.

소프트웨어는 실세계를 모방한 것이 아니라 새롭게 창조하는것이다.

새롭게 만든 소프트웨어는 실세계와 다른 형태로 존재한다.

이질감이 해소되는 부분이었다. 모방이 아니라 새롭게 창조한다.

아무리 잘만들어도 실재의 먼 친척정도 될것이다. 라는 구절이 생각났다.

객체지향의 인지능력

사람은 경계로 사람과 사물들을 구분한다.

객체 지향이 직관적이고 쉽게 이해 할 수 있는 패러다임이라고 하는 이유

->세상을 자율적이고 독립적인 객체들로 (경계)분해 할 수 있는 사람의 인지 능력에 기반을 둔다.

실 세상을 모방하는 것이 아니라 새롭게 창조하는 것이다.

사람의 손이 없어도 켜지는 전등, 카드 결제 하면 비용을 전달하는것처럼 새로운 기능을 안고 창조된다.

이상한 나라의 앨리스

읽을 때는 뭐지 했는데 읽고 나서 객체에 대한 상태, 행동, 식별자에 대해 알 수 있었다.

인문학을 읽는 착각? 자기 계발서 같은 심도 있는 의미도 느꼈다.

앨리스라는 객체가 가지고 있는 상태를 변경하기 위해서 앨리스는 행동한다.

작은 문에 들어가기 위한 목적을 위해서

식별자(앨리스)

앨리스가 나이가 어릴 때나 나이가 들어서도 앨리스는 앨리스이다.

키가 크건 못생기건 우리가 바라보는 앨리스는 항상 앨리스이다.

객체는 상태가 어떻게 변해도 유일한 존재이다.

상태

상태는 과거에 영향을 받는다.

과거의 이력을 모두 보기 보다는 현재의 상태(값)를 가짐으로써 과거를 확인 하지 않아도 된다.

행동

목적을 위해서는 움직여야 한다.

작은 문에 들어가기 위해서

프로퍼티와 프로퍼티 값

프로퍼티는 특정 명칭을 뜻하는 변수이다.(정적)

프로퍼티값은 변수에 들려 있는 값이다.(동적)

실 세계의 객체와 소프트웨어의 객체

앨리스가 음료를 마신다.

앨리스는 마시고 음료는 마셔진다.

소프트웨어에서는 앨리스라는 객체와 음료라는 객체는 각각의 자율성을 가지고 있다.

앨리스 객체의 행동이 음료 객체에 영향을 미치지만 음료는 자율적으로 스스로의 상태를 변경해야 한다.

의존 관계

행동의 결과는 객체의 상태에 의존한다.

전날에 야근을 하고 다음날 출근하면 컨디션이 굉장히 안좋아서 능률이 저하된다.

상태 캡슐화

|앨리스| -> 음료를 마신다 -> |음료| 

음료를 마신다는 행동은 알 수 있지만 음료의 상태는 알 수 없다.

내부와 외부를 구분한다.

현재의 상태를 노출 시키지 않음으로써 자율성을 높인다.

식별자

동등성 : 숫자 1과 숫자 1이 있다. 두 개의 값이 같은 것을 동등성이라고 한다.

동일성 : 어제의 나와 오늘의 나는 같은 사람(객체)이고 동일성이라고 한다.

기계의 객체

객체를 기계에 비유하여 설명했다. 라디오가 떠올랐다.

주파수를 옮기는 행동에 따라 주파수 상태가 바뀌고 같은 라디오가 2대 있어도 같은 라디오가 아니다.

스피커와 라디오가 협력 할 수 있지만 스피커의 전원과 소리의 상태는 스피커라는 객체에서만 할 수 있다.

의인화

추상화 : 실 세계의 모든 것을 담지 않고 원하는 특성만 골라내어 새로운 객체를 만들어 단순화한다는 의미

소프트웨어는 태어나고 삶을 영위하다가 죽는다.

은유

소프트웨어를 잘 이해하고 유지보수를 편리하게 하기 위해서 의미적, 표현적으로 실세계의 용어를 사용하라고 권장하는 것이다.

ex) 사람을 person이라는 객체로 만들고, 핸드폰을 phone이라고 하는 것처럼

소프트웨어에서는 영화 속 캐릭터처럼 사람에게 능력을 부여 하고 사용 할 수 있다.

실 세계와 다른 점이다. 

3. 타입과 추상화 

2019.01.18(금)-다시 읽기로 했다

2019.01.19(토)-다시 읽었다.

컴퓨터를 조작하는 일이 추상화를 구축하고, 조작하고, 추론하는 것에 관한 모든 것이라는 것을 깨닫고 나면 프로그램을 작성하기 위한 중요한 전제 조건은 추상화를 정확하게 다루는 능력이라는 것이 명확해진다.
- 키스 데블린(2003)

런던 지하철 개통과 노선도

노선도의 목적은 손님이 현재 역에서 원하는 목적지 역까지 가려면 어떻게 가야하는지 알기 위한 목적이다.

초기 노선도는 지형까지 고려했고 지도를 보는데 불필요한 부분으로 혼란을 가중 했지만 추후 역에서 역으로의 연결의 목적에면 충실하고 불필요한 부분을 제거함으로써 현대까지 계속해서 쓰이고 있다.

추상화

"현상은 복잡하다. 법칙은 간단하다. 버릴게 무엇인지 알아내라"

새로운 세상을 창조하는데 필요한 부분만 간추려 낸다. 세상에 존재하는 모든걸 만들려면 복잡해진다. 만들려고 하는 객체에게 필요한 부분만 차용한다.

복잡성을 다루기 위해 추상화는 두 차원에서 이루어 진다. - Kramer(2007)

첫번째 차원은 구체적인 사물들 간의 공통점은 취하고 차이점은 버리는 일반화를 통해 단순하게 만드는 것이다.

두번째 차원은 중요한 부분을 강조하기 위해 불필요한 세부 사항을 제거함으로써 단순하게 만드는 것이다.
-> 모든 경우에 추상화의 목적은 복잡성을 이해하기 쉬운 수준으로 단순화하는 것이라는 점을 기억하라.

그룹으로 나누기/ 일반화와 특수화

집합을 생각하라.

공통점을 찾아내어 하나의 집합으로 생각하여 불필요한 정보를 추리고 추상화 할 수 있는 시작점이다.

같은 공통점을 지니지만 새로운 기능을 가진 부분집합을 생각하면 부모와 자식을 추상화 할 수 있다.

일반화와 특수화

일반적인것은 보편적이다.

특수한것인 일반적인 면을 갖추지만 고유의 것이 있다.

합집합과 부분집합으로 생각 할 수 있다.

개념

객체란 특정한 개념을 적용할 수 있는 구체적인 사물을 의미한다. 

개념이 객체에 적용 됐을 때 객체를 개념의 인스턴스라고 한다.

심벌 : 개념을 가리키는 간략한 이름이나 명칭

집합을 존칭하는 명칭

내연 : 개념의 완전한 정의를 나타내며 내연의 의미를 이용해 객체가 개념에 속하는지를 확인
        집합에 속하는 것들을 이루는 개념

외연 : 개념에 속하는 모든 객체의 집합 : 우리가 알고 있는 집합

타입

이 파트에서 헷갈리는 부분이 있어서 다시 읽었다.

타입은 개념이다. 가장 어려운 말이었다.

데이터 타입. 오히려 이게 더 쉽게 와 닿았다.

"개념이 없다." 라는 말은 구분이 없고 분류가 없다는 말과 같다.
"타입이 없다." 라는 말은 데이터의 구분이 없고 데이터의 분류가 없다는 말과 같다.
숫자형 타입, 문자형 타입, 참/거짓 타입이 없이 0과 1로만 데이터를 구분하고 분류한다면 데이터를 바로 보고 파악 하기 어렵기 때문에 개념이 모호하다라거나 없다고 한다.
정말 천재라서 0과 1의 연속 된 자리를 보고 바로바로 연산하는 사람을 빼고는 개념이 없다고 보는게 맞다."

생각의 흐름에 따라 데이터 타입은 작은 단위의 타입이고 큰 단위의 타입은 객체가 될 수 있다. 

객체와 타입, 그리고 행동

결국에 행동이 우선이다.

데이터를 생각하고 타입을 결정하기 보다는 해야 하는 행동에 맞추어 타입과 객체를 결정해야 한다.

연산을 하는 행동하겠다는 행동으로 타입(개념이자 집합)에 맞는 객체를 결정한다.

예를 들어 밥을 준다. 누구에게 줄것인가? 강아지? 고양이 고양이다. 그러면 어떤 사료를 줄것인가? 내가 먹던 밥? 사람 먹는 참치? 로얄 캐닌? 로얄 캐닌을 줄것이다. 라는 것처럼. 행동을 우선하여 객체와 데이터를 결정한다.

클래스

타입을 구현하기 위한 방법이 클래스라는 방법이다.

타입은 개념이자 객체이자 구분을 가진 집합이다.

4. 책임, 역할, 협력

2019.01.20 읽었으나 다시 읽기로 함

2019.01.21 다시 읽음

놓여진 상황에서 협력을 하기 위해 역할을 정하고 역할에 대한 책임을 다하여 행동한다.

협력

요청하고 응답하는 관계

요청에 따라 응답하고 응답을 위해 요청하고 요청에 따라 응답하고...

각자의 역할에 따라 책임을 다하기 위해 요청과 응답을 ㅏㄴ다.

책임

행동 할 의무가 있는 경우에는 책임을 다한다.
시민의 의무같이 행동으로 책임을 다해야 한다.

객체는 책임을 다히기 위해서 갖추어야 하는 하는 것, 아는 것이 있다.

하는 것 : 무엇을 할 수 있는가/ 외부에 제공해 줄 수 있는 서비스의 목록과 기능

아는 것 : 무엇을 알고 있는가/ 외부에 제공 해 줄 수 있는 정보와 상태

판사가 하는 것과 아는것, 증인이 하는 것과 아는 것

역할

책임의 집합

판사이자 왕이자 아버지인 사람의 다양한 역할

판사이자 여왕이자 어머니인 사람의 다양한 역할

판사라는 역할을 공유 할 수 있다.

판사라는 역할을 추상화하여 할 수 있는 사람에게 위임할 수 있다. / 다형성

객체 지향의 선입견 3가지

1. 데이터를 저장하기 위해 존재하지 않는다. 

-> 놓여진 상황에서 협력을 위해 존재한다.

2. 클래스와 클래스의 관계를 표현하는 정적인 내용이 아니다. 

-> 놓여진 상황에서 동적으로 협력에 중점을 둔다.

3. 왕이라는 객체에 집중한다. 

-> 놓여진 상황에서 왕이 가지는 역할과 책임을 고려한다.

객체 지향 설계 기법

1. 책임 주도 설계(RDD) : 협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당하는 방식의 설계

2. 디자인 패턴 : 전문가들이 만들어 놓은 텔플릿 모음

3. 테스트 주도 개발(TDD) : 테스트는 부수적인 효과일뿐, 역할, 책임, 협력을 식별하고 식별 된 역할, 책임, 협력이 적합한지를 피드백 받는 개발 방법

5. 책임과 메시지

2019.01.22 : 이전에 나왔던 내용이랑 비슷한거 아닌가해서 다시 읽기로 했다.

2019.01.23 : 객체 지향의 핵심은 추상화를 얼마나 잘하는가인거 같다.

HOW/WHAT : '어떻게'가 아니라 '무엇'을 할지를 결정한다.
WHAT/WHO : '어떤' 행위를 수행할것인지를 결정하고 '누가' 행 할것인지를 결정한다.
객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택해야 한다.

행동에 책임이 따르는걸까, 책임에 행동이 따르는걸까 하는 생각이 들었다.
행동에 책임이 따라야 도의적인이고 자율적인 책임이라고 생각한다.

자율적인 책임

자율이란 자기 스스로의 원칙에 따라 어던 일을 하거나 자신을 통제해서 절제하는 성질과 특성을 가진다.

재판에서 증인이 '증언하다' 라는 행동은 '어떤' 증인이나 같지만 '무엇'을 증언 할지는 증인의 의지를 따른다.

객체의 행동은 같지만 상태에 따라 내용과 결과가 달라진다.

메시지와 메서드/ 메시지를 따라라

객체가 메시지를 수신 할 수 있다는 것은 객체가 메시지에 해당하는 책임을 수행 할 수 있다는 것을 의미한다.

요청과 응답을 메시지를 통해 이루어진다. 
메시지는 객체 지향의 핵심이다.

What/Who 사이클 : 어떤 행위(what)를 수행 할 것인가를 결정한 후에 누가(who) 그 행위를 수행 할 것인지를 결정

묻지 말고 시켜라 : 어떤 객체가 필요한지를 생각하지 말고 어떤 메시지가 필요한지 먼저 고민하라.

"메시지가 '어떻게' 해야 하는지를 지시하지 말고 '무엇'을 해야 하는지를 요청" - Metz(2012)

객체 인터페이스

인터페이스는 내부와 외부로 나뉘며 외부에서 공개 된 인터페이스를 공용 인터페이스라고 한다.

객체를 구성하지만 공용 인터페이스에 포함되지 않는 모든 것이 구현에 포함 된다.

소프트웨어는 항상 변경 되기 때문에 내부와 외부를 명확하게 분리해서 고려 해야 한다.

- 상태와 행위의 캡슐화

-> 자신의 상태를 관리하며 상태를 변경하고 외부에 응답 할 수 있는 행동을 내부에 보관한다. 
    상태와 행동을 하나의 단위로 묶은 자율적인 실체다. 이 관점이 데이터 캡슐화라고 한다.

- 사적인 비밀의 캡슐화

-> 외부의 객체가 자신의 내부 상태를 직접 관찰하거나 제어 할 수 없도록 소통 가능한 특별한 경로만 외부에 노출한다. 
    이처럼 외부에서 객체와 의사 소통 할 수 있는 고정 된 경로를 공용 인터페이스라고 한다.

2가지 측면이 잘 이해 되지 않아서 위키백과를 참조 헀다.

캡슐화(영어: encapsulation)는 객체 지향 프로그래밍에서 다음 2가지 측면이 있다:^[1][2]

• 객체의 속성(data fields)과 행위(메서드, methods)를 하나로 묶고,^[3][4]
• 실제 구현 내용 일부를 외부에 감추어 은닉한다.^[5][6]

6. 객체 지도

2019.01.24 : 다시 한번 정독하기로 함

2019.01.25 : 개발을 할 때 설계 문서를 갖추어야 하는 이유를 알게 되었다. 바라보는 관점의 다양화

길을 찾기 위해 지나가는 사람에게 물어보는건 단기적인 해결책.

길을 찾기 위해 지도를 보고 길을 찾아가는건 장기적인 해결책.

매번 길을 찾기 위해서 사람들에게 물어보기보다는 지도를 보고 찾아가는게 장기적으로 좋다.

기능과 구조의 조화

길을 물어서 가는 방법은 기능적

지도를 이용하는 방법은 구조적

길을 찾는게 목적이므로 길을 물어서 가는 방법이 사용자 측면에서는 편리하다.

길에 사람이 없거나 물어보는 사람이 길을 모르는 경우에는 지도를 볼줄 알아야 한다.

무슨 말인가

소프트웨어는 사용자가 무엇을 원하는지, 

원하는 것을 만족시키기 위해 시스템이 어떤 기능을 제공해야 하는지 초점을 맞추어야 한다.

사용자의 요구사항을 해결하기 위해서 기능적 측면에서 바라보고
시스템을 유지보수 및 변경 가능하기 쉽도록 구조적 측면으로 바라봐야한다.
결국 두 관점에서 잘 보고 만들어야 한다.

두 관점에서 바라보는 방법

구조적 측면

미래를 이야기 할 수 있고, 놀 수 있고 추측 할 수 있고, 깊이 생각해볼 수 있으며, 이론과 모형을 구축하고 이에 영향을 미치는 정량 데이터를 수집할 수 있지만 미래를 전혀 알지 못한다.

불확실한 미래의 변경을 예측하고 이를 성급하게 설계에 반영하는 것은 불필요하게 복잡한 설계를 낳을 뿐이다.

우리는 미래를 예측할 수 없다. 단지 대비 할 수 있을 뿐이다.

미래를 예측 할 수 없고 대비 하기 위해서 변경하기 쉬운 형태의 구조를 가진 소프트웨어를 만들어야 한다.

이를 위한 방법으로 도메인 주도 설계(DDD : Domain Driven Design) 가 있다.

도메인 모델

사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태다.

사자가 가지고 있는 생각 중 중요한 부분을 가지고 단순화한 구조다.

도메인 모델은 이해관계자들이 바라보는 멘탈모델이다.

- 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형.

멘탈 모델은 사용자 모델, 디자인 모델, 시스템 모델 세 가지 이미지로 구분한다.

디자인 모델 -> 시스템 모델 <- -> 사용자 모델

사용자가 생각하는 시스템이 사용자 모델이다.

설계자(개발자)가 생각하는 시스템이 디자인 모델이다.

시스템 모델은 디자인 모델의 산출물이고 사용자 모델과 상호작용(서비스 이용)을 한다.

시스템 모델이 얼마나 사용자 모델이 생각하는 바와 비슷한지에 따라 완성도가 정해진다.

이러한 세가지 관점이 유사하게 유지하는 것을 객체 지향에서 연결완전성 또는 표현적 차이 라고 한다.

표현적 차이

소프트웨어는 실 세상을 반영한 것이 아니라 재창조해 냈기 때문에 실 세상과 다르다.

새롭게 창조 된 세상을 좀 더 쉽게 표현하기 위해 은유를 사용한다.

실 세상에 존재하는 언어로 새롭게 창조 된 세상을 표현해서 사용자모델, 시스템 모델, 디자인 모델의 생각의 차이를 줄여나갈 수 있다.

구조적 측면에서 변경 가능하기 쉬운 모델을 만들기 위해서는 세분화 하여 나누어 관리하는 방법이다.

정기 적금, 계좌, 이자, 이자율 등의 객체를 만들어 개별적으로 관리하도록 한다.

최소한의 내용만 가지고 있는다.

정기 적금    :    기간, 해지 여부

계좌          :    계좌 번호, 예금액

이자          :    금액, 지급 일자

이자율       :    금리

기능적 측면

사용자의 목적과 목표에 부응하는 설계를 가져야 한다.

이를 표현하는 방법으로 유스케이스를 들 수 있다.

유스케이스

사용자의 행위에 대해서 시나리오를 가지고 있는 집합이다.

유스케이스를 사용하면 행위에 대한 시나리오들을 나열하여 사용자가 원하는 기능에 대해 바로 알아볼 수 있고 만족하는지 혹인 가능하다.

7.함께 모으기

2019.01.26 : 드디어 다 읽었다. 다시 읽어도 좋은 책이다. 덕분에 다른 책 몇권을 더 구매했다.

책에서 몇 안되는 코드를 보았는데 오아시스를 보는 기분이었다.

개념 관점

개념 관점에서 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다.

재차 강조하는 이야기지만 소프트웨어는 새롭게 창조한 세상이고 새롭게 창조한 세상을 이해하기 쉽게 전달하기 위해 실 세상에 존재하는 표현들을 빌려서 은유한다.

개념적 관점에서는 도메인 모델과 같이 새롭게 창조한 세상과 실세상을 비슷하게 만들면 수정이나 보완을 해야 하는 양이 줄어드는 장점이 있다.

명세 관점

개발자의 영역에 초점을 맞춘 관점이다.

객체간에 협력을 위해서 '무엇'을 할 수 있는가에 초점을 맞춘다.

"구현이 아니라 인터페이스에 대해 프로그래밍 하라" - GOF(1994)

명세 관점은 인터페이스 관점이고 실제 구현과는 다른부분이다.

공용 인터페이스에 해당하는 관점으로 바라보아야 한다. 

외부 객체가 해당 객체에 접근 할 수 있는 유일한 부분이다.

구현 관점

어떻게 '책임'을 수행 할것인지를 맞춘 관점이다.

실제 구현하는 코드에 속하며 외부 객체에 영향을 미쳐서는 안된다.

메서드와 속성은 클래스 내부에서만 확인 할 수 있는 캡슐화가 되어야 한다.

인터페이스와 구현을 분리하라.

명세 관점과 구현 관점을 철저하게 분리해야 한다.

인터페이스가 구현에 관한 사항을 노출하게 되면 작은 변경에도 시스템은 걷잡을 수 없게 흔들린다.

캡슐화를 위반해서 구현을 인터페이스 밖으로 노출해서도 안되고, 인터페이스와 구현을 명확하게 분리하지 않고 흐릿하게 섞어 놓아서도 안된다.

참고 내용

설계를 간단히 끝내고 최대한 빨리 구현에 돌입하라. 

머릿속에 객체의 협력 구조가 번뜩인다면 그대로 코드를 구현하기 시작하라.

설계가 제대로 그려지지 않는다면 고민하지 말고 실제로 코드를 작성해가면서 협력의 전체적인 밑그림을 그려보라.

테스트-주도-설계로 코드를 구현하는 사람들이 하는 작업이 바로 이것이다.

그들은 테스트 코드를 작성해 가면서 협력을 설계한다.

후기

객체에 대한 개념을 어렴풋이 알고 있던 생각을 윤곽이 잡히게 해준 책이다.

간혹 심도 있는 내용이 있어서 자기 계발서?인듯한 느낌도 받고 여러 방면에서 좋은 책이었다.

왜 추천하는지 알 거 같다.

다시 개발을 시작하는 나에게도 이제 시작하는 사람에게도 읽어보기 좋은 책이다.