라이브러리, 프레임워크 또는 기타 복잡한 클래스 집합에 대한 단순화된 인터페이스를 제공하는 구조적 디자인 패턴 전화로 주문하기 복잡한 프레임워크에 속하는 여러 개체들을 이용하여 코드를 초기화 하고 작동시켜야 한다고 가정해보자 아래와 같은 과정을 모든 개체에 해 주어야 한다. 올바른 순서로 개체 초기화 개체간 종속성을 추적 올바른 순서로 메서드를 실행 결과적으로 클래스의 비즈니스 논리가 타사 프레임워크 클래스의 구현 세부 정보와 밀접하게 연결되어 이해하고 유지 관리하기가 어렵다. 이럴 경우 facade 패턴을 통해 문제를 해결 한다. class diagram 어느때 사용해야 하는가? 복잡한 하위 시스템에 대한 제한적이지만 간단한 인터페이스가 필요한 경우 하위 시스템을 계층으로 구성하려는 경우 주요장점 패턴..

주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있다. 옷을 입는 것은 데코레이터의 좋은 예 추우면 스웨터를 입고 위에 재킷을 입을 수도 있다. 또 비가 오면 비옷을 입을 수 있다. 모든 옷은 기본 행동을 확장 하지만 자신의 일부는 아니다. 필요하지 않으면 쉽게 옷을 벗을 수 있다. class diagram 코드를 손상시키지 않고 런타임에 개체에 추가 동작을 할당할 수 있어야 하는 경우 데코레이터 패턴을 사용 상속을 사용하여 개체의 동작을 확장하는 것이 어색하거나 불가능할 때 데코레이터 패턴을 사용 아래 코드는 대검과 단검에 추가적인 효과를 주어 무기를 강화 시키는 것이다. 독과 대못을 추가 할 수 있고 이 기능..

객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한다. 위와 같이 특정 제품들을 모아놓은 box 의 총 가격을 계산한다고 가정하자 각각을 다 풀어서 계산 할 수 있지만 프로그램상에서는 다음과 같은 과정이 필요하다. 각 class 들의 특성(사용법) 및 method 를 알아야 한다. 각 class 들의 가격을 담당하는 특성 및 interface 를 client 가 알고 있어야한다. 각 class 들의 가격은 최종 가격일 수도 있고 client 에서 다시 계산해줘야 할 수도 있다. 위와 같은 과정을 거쳐야 해당 제품의 가격을 알 수 있다. 이건 너무 복잡하고 힘든 과정이다. 총 가격을 계산하는 방법을 선언하는 공통 인터페이스를 통해..

큰 클래스 또는 밀접하게 관련된 클래스 집합을 서로 독립적으로 개발할 수 있는 두 개의 개별 계층(추상화 및 구현)으로 분할할 수 있는 구조적 디자인 패턴. 기능 클래스 계층 ||=========|| 구현클래스 계층 전사와 도적이 존재 한다고 하자 전사가 대검으로 공격 할 수도 있고 단검으로 공격 할 수도 있다. 도적이 대검으로 공격 할 수도 있고 단검으로 공격 할 수도 있다. 각각을 class 로 구성 하려만 아래와 같이 서로 다른 4개의 class 로 구성된다. 전사+대검 전사+단검 도적+대검 도적+단검 이 상황에서 쌍검이 라는 새로운 무기를 추가 하려면 어떻게 될까? 또 직업중 암살자가 추가된다면 어떻게 해야 할까? 이런 상황을 위에 bridge 패턴을 이용하여 해결해 보자 Abstraction 에..

Adapter 호환되지 않는 인터페이스를 가진 개체가 서로 협업할 수 있도록 하는 구조적 디자인 패턴 ** 구조적 패턴 ** : 구조를 유연하고 효율적으로 유지하면서 개체와 클래스를 더 큰 구조로 조립하는 방법을 설명 간단히 UML 로 표현하자면 아래와 같다. Client : adapter 를 사용 하여 adaptee 쪽 동작을 하려는 사용자 Adaptee : client 에 노출된 interface 만으로 접근할 수 없거나 사용할 수 없는 객체 또는 library Target Interface : client 가 접근할 수 있으며 adapter 가 구현하는 interface. 이 interface 를 통해 client 가 adaptee 를 호출할 수 있다. Adapter : client 와 adapte..