10장_유연한 설계

(설계의 여러 패턴을 설명하는 장)

• 개발이 진행될수록 현재의 레거시 코드로 인한 중압감에 시달리지 않고
  프로젝트 진행을 촉진하려면 변경을 수용하고 즐겁게 작업할 수 있는 유연한 설계(Supple Design)가 필요하다
• 너무 과도한 추상 계층과 간점 계층이 존재하면 오히려 유연성을 방해
  사용자에게 유용성을 제공하는 (좋은) 설계는 단순하다. 단순하다는것이 쉽다는 것을 의미하지는 않는다.
  조립가능하고 그럼에도 이해가기가 어렵지 않은 요소를 만들어내려려면 MDD를 적당한 수준의 엄밀한 설계 형식과 접목하고자 노력해야한다.
• SW를 유연하게 만드는 특별한 공식 같은 것은 없지만 개인적인 경험을 바탕으로 적절하게 적용할 경우 유연한 설계를 만들 수 있는 패턴 집합을 추려보았다
  그림10-1 유연한 설계에 기여하는 패턴 p260

Design Pattern	Description
의도를 드러내는 인터페이스 Intention Revealing Interface	- 개발자가 컴포넌트를 사용하기 위해 컴포넌트의 구현 세부사항을 고려해야한다면   캡슐화의 가치는 사라진다 - 개념을 Class나 Method 형태로 명확하게 모델링해서 가치를 얻으려면    도메인 개념을 반영하도록 Class와 Method이름을 지어야 한다   Class와 Method 이름은 개발자 간의 의사소통을 개선하고 시스템 추상화를 향상 - Interface를 구성하는 각 요소의 이름을 토대로 설계 의도를 드러낼 수 있는 기회...   Type Name, Method Name, Argument Name 이 모두 결합되어   Intention Revealing Interface를 형성 - 결과와 목적만을 표현하도록 클래스와 연산의 이름을 부여   이렇게 하면 (Client) 개발자가 내부를 이해해야할 필요성이 줄어듬   이름은 팀원들이 그 의미를 쉽게 추측할 수 있게 UL에 포함된 용어를 따라야함   그림 10-3 p264
부수효과가 없는 함수 Side Effect Free Function	- 부수효과를 일으키지 않으면서 결과를 변환하는 연산을 함수(Function) 이라고 함   함수는 여러번 호출해도 무방하며 매번 동일한 값을 반환 - 복잡한 계산을 이러한 패턴으로 분리하면 해결해야할 문제의 난이도를 낮출수 있음
단언 Assertion	- Assertion을 사용하면 Entity의 부수효과가 명확해지고 다루기 쉬워짐 (어렵다)
개념적 윤곽 - p277 Conceptual Contour	- 모델 또는 설계 구성 요소가 모노리식 구조에 묻혀 있을 경우 각 요소의 기능이 중복   Client는 외부 Interface로 부터 유용한 정보의 일부만 파악할 수 있을 뿐   서로 다른 개념이 뒤죽박죽으로 섞여있기 때문에 의미 파악 어려움 - 반대로 Class와 Method를 잘게 나누면 Client객체가 무의미하게 복잡해짐   이는 Client 객체가 작은 부분들의 협력 방식을 이해하고 있어야하기 때문이다 - 도메인 어딘가에는 나름의 논리가 있을테고, 그렇지 않다면 모델링이 무의미해진다   도메인에는 잠재적인 일관성이 존재하므로 도메인의 일부 영역에서   적절한 모델을 발견하면 이 모델이 나중에 발견되는 다른 영역과도   일관성을 유지할 가능성이 높다...   이것이 바로 반복적인 리팩터링을 통해 유연하 설계를 얻게되는 이유 중 하나   새로 알게된 개념이나 요구사항을 코드에 적용하다 보면 Conceptual Contour가 나타남 - 도메인의 중요영역을 나누는것과 관련한 직관을 감안해서 설계요소   (연산, 인터페이스, 클래스, Aggregate)를 응집력있는 단위로 분해,   계속적인 Refactoring을 토대로 변경되는 부분과   변경되지 않는 부분을 나누는 중심축을 식별,   변경을 분리하기 위한 패턴을 명확하게 표현하는 Conceptual Contour를 찾아라   (p280의 예제도 있지만 이해하기 어려움)
독립형 클래스 - p283 Standalone Class	- ... 모든 Method에 포함된 인자 타입 역시 의존성을 의미, 반환 타입에 대해서도 마찬가지 - Module과 Aggregate 모두 지나치게 얽히고설키는 상호의존성을 방지하는 것이 목적 - Module내에서조차 의존성이 증가할수록 설계를 파악하는 어려움 - 낮은 결합도는 객체 설계의 기본 원리, 가능한 한 늘 결합도를 낮추고자 노력하라 - 그러면 클래스가 완전히 독립적 Self Contained 으로 바뀌고 단독으로 검토하고 이해
연산의 닫힘 - p296 Closure of Operation	(어렵다)