1. 디자인 패턴과 설계 재사용
소프트웨어 패턴
- GoF의 디자인 패턴
- 마틴 파울러의 Analysis Patterns에서의 패턴정의
- 하나의 실무 컨텍스트(practical context)에서 유용하게 사용해 왔고 다른 실무 컨텍스트에서도 유용할 것이라고 예상되는 아이디어
- 3의 규칙
- 최소 세 가지의 서로 다른 시스템에 특별한 문제 없이 적용 할 수 있음
- 미리 정해진 패턴을 사용함으로써 높은 수준의 대화를 가능하게 함
- 패턴은 홀로 존재하지 않음
- 패턴 언어와 패턴 시스템
패턴 분류
- 4가지의 패턴 분류
- 아키텍처 패턴
- 분석 패턴
- 도메인 내의 개념적인 문제를 해결하는데 초점을 맞춤
- 업무 모델링 시에 발견되는 공통적인 구조를 표현하는 개념들의 집합
- 디자인 패턴
- 이디엄
패턴과 책임-주도 설계
- 객체지향에서 가장 중요한건 올바른 책임을 올바른 객체에게 할당, 객체간 유연한 협력 관계를 구축하는것
- 책임과 협력의 윤곽은 캡슐화, 크기, 의존성, 유연성, 성능, 확장 가능성, 재사용성 등 다양한 요소들의 트레이드오프를 통해 결정됨
- 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿
- 패턴을 따르면 특정한 상황에 적용할 수 있는 설계를 쉽고 빠르게 떠올릴수 있음
- 책임 주도 설계의 절차를 하나하나 따르지 않고 구현할 객체들의 역할, 책임, 협력 관계를 빠르고 쉽게 구성할 수 있음
- 패턴의 구성요소는 클래스가 아니라 역할
- [디자인 패턴 설명]
- 디자인 패턴의 구성요소가 클래스와 메서드가 아니라 역할과 책이라는 사실을 이해하는 것이 중요
캡슐화와 디자인 패턴
- 몇 가지 이례적인 경우를 제외하면 널리 알려진 디자인 패턴은 협력을 일관성 있고 유연하게 만드는 것을 목적으로 함
- 영화 예매 시스테에서
Movie
와 DiscountPolicy
는 STRATEGY 패턴을 적용한 것 (합성) - 영화에 적용될 할인 정책의 종류는 DiscountPolicy의 서브클래스가 무엇이냐에 따라 결정됨
- 상속 관계를 이용하면 TEMPLATE METHOD 패턴이라고함
- 부모 클래스가 알고리즘의 기본 구조를 정의하고 구체적인 단계는 자식 클래스에서 정의하게 함으로써 변경을 캡슐화할 수 있는 디자인 패턴
- 핸드폰 과금 시스템 설계는 DECORATOR 패턴을 기반으로 함
- 객체의 행동을 동적으로 추가할수 있게 해주는 패턴
- 디자인 패턴에서 중요한건 구현 방법이나 구조가 아님
- 어떤 디자인 패턴이 어떤 변경을 캡슐화하는지 이해하는것이 중요
- 각 패턴이 변경을 캡슐화하기 위해 어떤 방법을 사용하는지 이해하는것이 중요
패턴은 출발점이다
- 패턴이 목표가 되어서는 안됨
- 패턴은 단지 목표로 하는 설계에 이를 수 있는 방향을 제시
- 목적에 맞게 수정
- 패턴 사용시 부딪히는 대부분의 문제는 패턴을 맹목적으로 사용할때 발생
- 해결하려는 문제가 아니라 패턴이 제시하는 구조를 맹목적으로 따르는것은 불필요하게 복잡, 난해, 유지보수하기 어려운 시스템을 만듦
- 다양한 트레이드오프 관계속에서 패턴을 적용하고 사용해본 경험이 필요
- 어떤 컨텍스트에서 어떤 패턴을 적용해야하는지, 더 중요한것은 어떤 패턴을 적용하면 안되는지 감각을 가지고 있어야함
- 조슈아 케리에브스키의 패턴을 가장 효과적으로 적용하는 방법
- 패턴이 적용된 최종 결과를 이해하는 것보다는 패턴을 목표로 리팩터링 하는 이유를 이해하는 것이 훨씬 가치 있으며, 훌륭한 소프트웨어 설계가 발전해온 과정을 공부하는 것이 훌륭한 설계 자체를 공부하는 것보다 훨씬 중요하다고 이야기함
2. 프레임워크와 코드 재사용
코드 재사용 대 설계 재사용
- 디자인 패턴은 언어에 종속적이지 않음
- 즉 설계 아이디어를 언어의 특정에 맞게 가공하고 매번 구현 코드를 재작성해야한다는 단점이 있음
- 가장 이상적인 형태의 재사용 방법은 설계 재사용과 코드 재사용을 적절한 수준으로 조합하는것
- 프레임워크란?
- 추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계
- 애플리케이션 개발자가 현재의 요구사항에 맞게 커스터마이징할 수 있는 애플리케이션의 골격(skeleton)
상위 정책과 하위 정책으로 패키지 분리하기
- 프레임워크의 핵심은 추상 클래스나 인터페이스 같은 추상화
- 객체지향 이전의 구조적인 설계와 같은 전통적인 소프트웨어 개발의 경우 상위 레벨 모듈이 하위 레벨 모듈에, 그리고 상위 정책이 구체적인 세부적인 사항에 의존해야했음
제어 역전 원리
- 상위 정책을 재사용한다는 것은 결국 도메인에 존재하는 핵심 개념들 사이의 협력 관계를 재사용한다는 것을 의미