짧은 요약

"객체지향 코드를 짜자. 무슨 데이터를 관리하는지도 중요하지만, 우선은 무슨 메시지가 오갈 것인지부터 알아내자. 코드는 그 후에 짜도 늦지 않다"

형광펜 쳐둔 문장들 일부

앞에서부터 훑어보면서 눈에 집히는대로, 약간씩 변형해서 기록.

• 컴파일 시점의 디펜던시와 런타임 시점의 디펜던시가 같은 것은 추상화가 잘 안되어있다는 의미일지도
• 설계가 유연해지면 디버깅은 어려워지고 재용성과 확장 가능성은 낮아진다 (trade-off)
• 인터페이스를 재사용할 목적이 아니라, 구현(code)을 재사용할 목적으로 상속을 사용하면 변경에 취약한 코드를 낳게 된다
• 역할, by 책임, by 협력.
• 객체의 상태가 아니라 행동에 집중하라
• 책임은 Information expert에게
• 객체가 책임을 수행하도록 하는 유일한 방법은 메시지를 전송하는 것
• 메시지가 객체를 선택하게 하라. 즉, 메시지를 정하고 그 메시지를 받을만한 객체를 식별하라 (책임 주도 설계. Not 데이터 주도 설계)
• 게터/세터에 의존하는 설계는 객체가 다양한 상황에서 사용될 것이라는 막연한 추측을 기반으로 설계하는 셈이다
• 협력이라는 Context 속에서 책임을 결정하라. 각각의 객체는 고립된 섬이 아니다.
• 최소한이면서 추상적인 인터페이스를 추구할 것
• 디미터 법칙 (오직 인접한 이웃하고만 대화하라 (즉 다른 객체에 깊이 알지 말라)), Tell, Don't Ask
• 클래스가, 하나의 이유만으로 변경되어야 한다. 메소드같은거 말고 클래스가.
• 조건문을 다형성으로 대체하라. 이렇게 하면 OCP는 자연히 확보된다.
• 지식이 결합을 낳는다.
• 코드가 방법(How)이 아닌 목적(What)에 집중하고있는지 수시로 체크하라
• DIP - 추상에 의존해야 한다
• 객체의 역할과 책임이 자리를 잡기 전에 너무 성급하게 객체 생성에 집중하지 말라. 중요한 비즈니스 로직을 처리하기 위해 책임을 할당하고 협력의 균형을 맞추는 것이 객체 생성에 관한 책임을 할당하는 것보다 우선이다.
• 상속을 이용할 때는 보다 구체적인 구현을 아래로 내리는 대신, 추상화에 의존하도록 공통분모를 위로 올려라.
• LSP - 클라이언트는 서브타입을 부모타입으로 바꿔도 문제가 없어야 한다
• OCP - 기능을 확장할 때 기존 코드를 수정할 필요가 없어야 한다

아쉬운 점

같은 말이 너무 많다. 그 공간들을 새로운 예시나 재밌는 사례들로 채웠으면 어땠을까. 하긴 뭐 반복해서 듣다보니 더 잘 기억나게 된 감도 없잖다만.

여기서 말하는 객체다움을 추구하면 DDD는 거의 필연적인 지향점인 듯하다. 그러나 요즘은 DDD 자체에 반신반의하기 때문에 흐음 스러운 부분투성이.

갑자기 든 생각인데, 이후의 코딩 책들은 책에 수록된 코드에 대해 좀 색을 다양하게 써줬으면 좋겠다. 꽤 판매에 도움될 것 같은데.