디자인 패턴 사전지식
디자인 패턴
각 디자인 패턴은 기존 환경 내에서 반복적으로 일어나는 문제들을 설명한 후, 그 문제들에 대한 해법의 핵심을 설명해 줍니다. 똑같은 방법으로 두 번 하지 않고 이 해법을 100만 번 이상 재사용할 수 있도록 말이죠 - 크리스토퍼 알렉산더
어떤 상황의 문제에 대한 (재사용 가능한) 해법
특정한 전후 관계에서 일반적 설계 문제를 해결하기 위해 상호 교류하는 수정 가능한 객체와 클래스들에 대한 설명
for OOD
패턴의 요소
패턴 이름(pattern name)
- 고도의 추상화
- 의사소통 간결
문제(problem)
해법(solution)
- 설계를 구성하는 요소들
- 요소들 간의 관계, 책임, 협력
결과(consequence)
- 패턴 적용 후 얻는 결과와 장단점
관계
점선관계는 상대적으로 실선관계보다 결합도가 낮다. 즉 점선 관계가 상대적으로 유연성이 높다
dependency(의존)
- 메소드 인자 타입
- 메소드 반환 타입
- 메소드 내 지역 변수 타입
- 큰 의미로는 연관관계도 의존관계의 하위 집합으로 분류할 수 있다고 본다. (개인생각)
Instance-Level
association(연관)
- 객체 레퍼런스를 객체 변수(field)로 지니고 있는가?
aggregation(집합) - 표준스팩 정의가 모호하므로 사용 비추천
- 부분과 전체 : 표준스팩이 이렇게만 설명하고 끝이다 ;;;;
- owner ship (이 부분은 표준스팩이 모호한 면이 있어서 참고로만 알아두자)
- 어떤 전체의 부분이 되는 객체가 다른 전체의 부분으로 되면 안된다.
- 부분의 ownership를 가지는 객체는 단 하나여야한다.
composition(합성)
- lifecycle이 같은가?
Instance-Level 관계
Type-Level
generalization(일반화)
클래스 상속
상속은 일반화로 부를 수 있지만 일반화 중 상속으로 부를 수 없는 경우도 있다.
상속과 일반화를 같은 의미로 쓰는 것이 틀렸다고 보기는 힘들다고 본다. 단, 두 개념이 완벽하게 같다고 보는 것은 경계하자.
realization(실체화)
인테페이스 구현
용어정리
class
- 속성과 행위를 가지는 추상화된 것
객체(object)
인스턴스(instance)
객체? 인스턴스?
인스턴스 : 분류를 기반으로 한 추상화 된 것에서 구체화된 것
- 인스턴스화(instantiation) : 클래스에서 객체로
- 분류(classification) : 객체에서 클래스로
인스턴스는 객체보다 좀 더 추상화된 개념이다
- 객체는 클래스의 인스턴스다.
- Row는 DB테이블의 인스턴스다.
- 객체 간의 링크는 클래스 간의 연관관계의 인스턴스다.
- 실행 프로세스는 프로그램의 인스턴스다.
속성(attribute)
- field
property? attribute?
- property : 외재속성(getter)
- attribute : 내재속성(field)
- 캡슐화
행위(behavior)
- 메서드
메세지(요청)
객체 간 협력 가능하게 하는 방법
- 객체는 메시지를 사용자(client)에게 받으면 연산(행위)을 수행
- 요청은 객체가 연산(행위)를 실행하게 하는 유일한 벙법
- 속성은 행위를 통해서만 변경 가능
시그너처(signature)
- 연산의 이름, 매개변수들, 반환타입의 명세
- java 등의 언어에서는 반환타입이 메소드 시그너처로 포함되지 않는다.
인터페이스
- 객체가 정의하는 연상의 모든 시그너처
- 객체가 받아서 처리할 수 있는 연산의 집합
- 외부에 오픈
타입
- 특정 인터페이스의 명칭
개념 -> 타입 -> 인터페이스(or 클래스)
다형성(polymorphism)
OOP에서는 사용자가 기대하는 객체를 동일한 인터페이스를 갖는 다른 객체로 대처할 수 있게 합니다. 이 대체성을 다형성이라고 합니다.
동일한 인터페이스를 갖는 것으로 추상화 시킬 수 있고 이로 인해 단순화할 수 있으며, 객체 간의 결합도를 낮출 수 있습니다. 인터페이에 대해서만 의존성을 가지고 있으면 이에 따른 어떤 구체화된 것을 사용하는지에 대해서 몰라도 되기 때문입니다.
디자인 패턴은 인터페이스에 정의해야 하는 중요 요소가 무엇이고 어떤 종류의 데이터를 주고 받아야 하는지 식별하여 인터페이스를 정의하도록 도와줍니다.
OO에서 확장에 열리는 부분(OCP)을 이 다형성이 가능하게 합니다.
구상클래스(Concrete Class)
- 구체화된 클래스
- 구현된 상세클래스
- 단단하다(concrete) -> 유연하지 못함
클래스 상속 vs 인터페이스 상속
구현이 아닌 인터페이스(추상화)에 따라 프로그래밍합니다.
- 추상화에 의존하면 의존성이 낮아지므로 더 유연한 프로그래밍이 가능하다.
- 인터페이스라는 객체군을 형성해서 자연스레 다형성을 끌어낼 수 있다.
상속 vs 구성
상속 : is a, is a kind of
구성(합성) : has a
- 상속의 경우 부모클래스의 내부가 서브클래스에 공개되기 때문에 일부 캡슐화가 위배된다
- 구성은 상속의 대안으로써 다른 객체의 참조를 얻어서 새로운 기능 혹은 객체를 구성하는 것
- 사용하는 객체의 내부가 공개되지 않는다 (참조를 가진 객체의 인터페이스를 통해서만 접근 가능)
- 상속은 컴파일 시 결정, 구성은 런타임 시 결정
객체 합성이 클래스 합성보다 더 나은 방법
자바 컨퍼런스에서 자바를 창시한 제임스 고슬링에게 한 프로그래머가 물었답니다. “자바를 다시 설계한다면 무엇을 없애고 싶습니까?” 그러자 고슬링이 “클래스를 없애고 싶습니다” 라고 했다더군요. 물론 다시 웃으면서 “그만큼 클래스 상속이 문제가 많으니 인터페이스 상속을사용해야 한다는 뜻이다” 라고 덧붙이긴 했답니다.
예시
- 상속(is a) : 템플릿 메서드 패턴
- 구성(has a) : 전략 패턴
위임
- 사전적인 의미는 맡긴다
- 구성된 다른 객체(has a)에 처리를 책임을 넘기는 것
- 처리를 메세지를 통해서 위임한다
디자인 패턴을 고르는 방법
- 패턴이 어떻게 문제를 해결하는가?
- 패턴의 의도를 파악
- 패턴들 간 관련성을 파악
- 비슷한 목적의 패턴을 그룹화
- 재설계의 원인 파악
- 설계에서 가변성을 가져야하는 부분이 무엇인지 파악
참고
- GoF의 디자인패턴 - GoF
- 자바 객체지향 디자인 패턴 - 정인상 외
- UML 실전에서는 이것만 쓴다 - 로버트.C.마틴
- 객체지향의 사실과 오해 - 조영호
