2010. 8. 24. 17:59
Pattern
출처 : http://cloudree.egloos.com/4454163
본문 인용 :
본문 인용 :
프로그래밍 기법 중의 하나인, 디자인 패턴을 배우고 싶으신 분에게 추천하는 책입니다.
책 구성은 어찌보면 정신 없을 수도 있지만,
그만큼 설명이 잘 되어있기 때문에 천천히 잘 따라가다보면 이해가 쉽습니다.
Head First Design Patterns (한빛 미디어, 서환수 역)
책에 있는 코드를 Java 대신 C#으로 제가 직접(!) 작성한 화일도 첨부합니다.
사실 C# 은 Java와 매우 비슷해서 거의 1:1 변환이 가능했습니다만,
몇가지 Java에 의존적인 예제와, 너무 소스가 큰것은 포기할 수 밖에 없었네요.
아래 내역은, 책 내용을 스터디 일환으로 정리했던 자료입니다.
PS. 그런데 이걸 IT 밸리로 보내도 되는 걸까나... 프로그래밍 밸리를 만들어 달라는 건 무리겠죠?
=====================================================
Head First Design Patterns 정리 by cloudree.egloos.com
경고) 책을 안 읽고 아래 내역을 보면 절대 이해 안 됨.
1.개요
1.잘 짜여진 구조를 편하게 적용
2.용어를 통한 쉽고 빠른 소통
3.OOP 가 문법이라면, DP는 구성방법
4.여러 DP를 조합해서 사용하는 경우도 많음
5.만능은 아니다
2.Strategy Pattern
1.(오리,인형오리,로켓오리)가 우는 방법, 나는 방법
2.상속되는 개체별로 많이 바뀌는 것을 (상속으로 구현하지 않고) 멤버로 구현
3.isA (상속) => hasA (구성)
1.상속의 단점 : 서브클래스에서 코드가 중복된다. 실행시 특징을 바꾸기 힘들다
3.Observer Pattern
1.날씨 확인 장치
2.주제와 옵저버
1.필요시 옵저버로 등록/제거
2.주제는 데이터를 옵저버에게 전송 (일대다)
3.주제이면서 옵저버일수 있음
3.느슨한 결합 Loose Coupling
4.Push / Pull
4.Decorator Pattern
1.수많은 종류의 커피의 가격 계산
2.객체에 추가적인 요건을 동적으로 첨가.
3.인터페이스는 바꾸지 않고 책임(기능)만 추가
4.Cost = costWhip( costMocha( costRoast( =0.99 ) + 0.2 ) + 0.1 )
5.OCP : Open-Close-Principle
5.Factory Pattern
1.피자 가게
2.여러 종류의 객체를 생성하는 방법
3.Simple Factory (Pattern에는 부족)
4.의존성 뒤집기 원칙 : Dependency Inversion Principle : 추상화된 것에 의존하도록 만들기. 구상 클래스에는 의존하지 않게.
1.일반적 사고 : 구상(피자 가게) => 다양한 피자(구상) => 피자(추상)
2.뒤집기 사고 : 피자(추상) => Factory => 다양한 피자(구상)
5.가급적 신경 써줄 가이드 라인
1.구상클래스에 대한 레퍼런스 사용 회피
1.CheesePizza *pizza 대신 Pizza *pizza 사용
2.구상 클래스에서 유도된 클래스 정의 회피
1.class NYStyleCheesePizza : public CheesePizza
3.베이스 클래스에서 구현된 메소드를 오버라이드 회피
1.베이스 클래스 자체가 잘 만들어진 추상 클래스가 아니라는 뜻
6.Factory Method Pattern
1.서로 연관된 또는 의존적인 객체들로 이루어진 제품군을 생성하기 위한 인터페이스를 저공.
2.생성할 구상 클래스를 서브클래스에서 결정함
7.Abstract Factory Pattern
1.객체를 생성하기 위한 인터페이스를 만듬.
2.클라이언트에서 구상클래스를 지정하지 않으면서도 일군의 객체를 생성할 수 있도록 함
8.FMP vs AFP 비교
1.여러 가지 상속을 통해 각기 다른 종류의 객체 생성(FMP) / (AFP) 구성(Composition)을 통해 다른 종류의 객체 생성
2.연관된 일련의 객체 생성에 유리(FMP) / (AFP)어떤 구상 클래스가 사용될지 미리 알수 없는 경우
6.Singleton Pattern
1.클래스 인스턴스가 하나만 만들어지도록 하고, 그 인스턴스에 대한 전역 접근을 허용
2.멀티프로세싱 주의
7.Command Pattern
1.식당에서 주문 → 웨이터 → 주방장
2.특정 객체에 대한 특정 작업 요청을 캡슐화
8.Adaptor Pattern
1.오리와 칠면조
2.한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환. 어댑터를 이용하면 인터페이스의 호환성 문제 때문에 같이 쓸 수 없는 클래스들를 연결해서 쓸 수 있음.
3.인터페이스를 변환
4.Object Adaptor : 구성(Composition)을 사용
5.Class Adaptor : 다중 상속으로 양쪽에 대해 adapt
9.Facade (퍼사드)
1.홈시어터 = DVD, 앰프, 프로젝터, 조명, 스크린 …
2.어떤 서브시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공. 퍼사드에서 고수준 인터페이스를 정의하기 때문에 서브시스템을 더 쉽게 사용
3.단순화된 인터페이스로 감쌈. 원래 것도 사용가능
4.최소 지식 원칙 : 상호작용 클래스 갯수를 줄이기 = 데메테르의 법칙
1.객체 자체
2.메소드에 매개변수로 전달된 객체
3.그 메소드에서 생성하거나 인스턴스를 만든 객체
4.그 객체에 속하는 구성요소
10.Template Methods Pattern
1.커피/차 끓이기의 공통점
2.메소드에서 알고리즘의 골격을 정의. 알고리즘의 여러 단계 중 일부는 서브클래스에서 구현 가능. 템플릿 메소드를 이용하면 알고리즘의 구조는 그대로 유지하면서 서브클래스에서 특정 단계를 재정의 가능
3.Hook : 확장을 위해 빈 메소드를 끼워넣어 두는 것 : 추상 함수로 만들지 않아도 되니 상속시의 부담이 줄어듬
4.헐리우드 원칙
1.먼저 연락하지마. 내가 먼저 연락할테니까
2.의존성 부패 (dependency rot) 방지 : 저수준 구성요소는 고수준 구성요소를 호출할 수 없게 구성
11.Iterator Pattern
1.식당메뉴+팬케이크메뉴
2.컬렉션 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 수 있게 하는 방법을 제공
3.응집도(Cohesion) : 클래스를 바꾸는 이유는 한가지 뿐 이어야 함 = 한 클래스에서는 한가지 역할만
4.Null Iterator : Null Object Design Pattern
12.Composite Pattern
1.식당(디저트)+팬케이크+디너
2.객체들을 크리구조로 구성하여 부분과 전체를 나타내는 계층구조로 만들수 있음.
3.서브메뉴의 구현:복합 객체와 개별 객체를 같은 식으로 관리
13.State Pattern
1.GumBallMachine
2.객체의 내부 상태가 바뀜에 따라 객체의 행동(beahavior)을 바꿔서 마치 객체의 클래스가 바뀌는 것 같은 결과
3.구성으로 가지고 있는 상태 변수를 다른 동작으로 상속된 구상 클래스의 인스턴스로 교체
4.스테이트 패턴 : 상태를 기반으로 하는 행동을 캡슐화 하고 행동을 현재 상태에 위임
스트래티지 패턴 : 알고리즘의 각 단계를 구현하는 방법을 (전략적으로) 서브클래스에서 구현
템플릿 메소드 패턴 : 바꿔쓸수 있는 행동(method)을 (템플릿에) 캡슐화한 다음 실제 행동은 다른 객체에 위임
14.Proxy Pattern
1.로컬용으로 만든 GumballMachine 모니터에 (원격 프록시)를 달아서 원격 처리
2.어떤 객체에 대한 접근을 제어하기 위한 용도로 대리인이나 대변인에 해당하는 객체를 제공하는 패턴
3.데코레이터 : 클래스에 새로운 행동을 추가하기 위한 용도
프록시 : 클래스에 대한 접근을 제어하기 위한 용도
어댑터 : 다른 객체의 인터페이스를 바꿔주는 용도
퍼사드 : 여러 객체를 감싸서 인터페이스를 단순화 시킵니다.
4.동적 프록시, 가상 프록시, 원격 프록시, 보호 프록시
15.Compound Pattern
1.여러 패턴을 섞어쓰는 패턴 : 꽥카운터(데코레이터)+꽥옵저버+오리팩토리+오리컴포지트 of [오리(스트래티지)+아답터(거위)]...
- 어댑터로 거위를 감싸서 오리처럼 처리
- 꽥 횟수를 세기위해 데코레이터 패턴 도입
- 오리 종류 추가를 편하게 하기 위해 팩토리 패턴 도입
- 오리떼 관리를 위해 컴포지트 패턴 도입
- 오리 소리를 추적하기 위해 옵저버 패턴 도입
2.모델-뷰-콘트롤러 (MVC)
- 스트래티지 패턴 : 뷰에서 "유저 행동"에 관련된 작업을 컨트롤러에게 위임
- 옵저버 패턴 : 모델의 변경을 뷰/콘트롤러가 관찰
- 컴포지트 패턴 : 뷰의 UI는 컴포지트 체계
16.기타 패턴
1.Bridge Pattern : 구현과 인터페이스의 분리
2.Builder Pattern : 복합객체 생성 과정을 캡슐화
3.Chain of Responsibility : 역할 사슬 = 윈도우 이벤트 드라이버
4.Flyweight : 가벼운 나무 그리기 객체
5.Interpreter : 인터프리터
6.Mediator : 통신 중앙 집중형
7.Memento : 상태와 객체의 분리 = 객체 상태의 저장 및 복원
8.Prototype : 인스턴스의 복사를 통한 객체 생성
9.Visitor : traverser 객체가 Composite 객체의 기능을 보완
17.맺음
- [특정 컨텍스트 내에서 주어진 문제에 대한 해결책]
- 반복적으로 적용 가능한 상황에서 제약조건에 맞게 사용
- 어떤 컨텍스트 내에서 일련의 제약조건에 의해 영향을 받을수있는 문제에 본착했다면
그 제약조건 내에서 목적을 달성하기 위한 해결책을 찾아낼수 있는 디자인을 적용하면 된다
- GoF 의 패턴 카탈로그
