전체 글

전체 글

    (행동패턴) 커맨드 패턴

    사용 시점 및 이유 수행할 동작을 매게변수화 하고자 할 때 (callback을 객체지향화) undo(실행 취소) 기능을 구현하고 싶을 때. 실행할 연산들을 별도로 저장하여 장애 대응 시 편리하게 연산을 다시 실행하고 싶을 때 구현 Client는 Command와 Receiver를 이용하여 Invoker 를 생성한다. undo기능이 필요 할 경우 Invoker에서 실행한 커맨드들을 List로 가지고 있고(혹은 stack), command에서도 unExecute()를 구현한다. 장애시 연산 저장과 같은 기능을 원할 경우 Command 객체들을 직렬화 하여 별도로 저장해 둔다. Invoker는 자신이 어떤 Command 구상클래스를 가지고 어떤 명령을 실행하는지는 알 수 없다.

    (행동패턴) 책임연쇄패턴

    사용 시점 및 이유 요청을 처리할 객체들의 집합이 동적으로 정의 되어야 할 때 연결되어 있는 각 객체들에게 요청을 건내고, 그중 하나가 처리하면 될 때 (처리하고 종료하는 방식) 어느 객체의 핵심 로직에 대해서 부가기능들을 동적으로 추가하고 싶을 때 (계속해서 전달 하는 방식) 구현 각 책임을 가진 구상 객체들은 BaseHandler를 상속받아 구현한다. 구상 핸들러 객체는 자신이 실행할 수 있는 명령일 경우 실행하고 종료할 수도 있다. (처리 하고 종료) 구상 핸들러 객체는 자신의 기능을 실행하고 연결된 Next Handler를 실행하도록 할 수 있다(전달)

    (구조패턴) 프록시 패턴

    사용 시점 및 이유 레이지로딩 등 목표 클레스에 대한 접근을 제어할 필요가 있을 때 구현 클라이언트는 interface를 바라보며, 프록시 객체인지 실제 객체인지 알 필요가 없다. proxy는 실제 객체와 동일한 인터페이스를 구현하며, 실제 객체를 멤버로 가지고 있는다. 클라이언트의 실행은 프록시로 전달되고, 프록시는 기능을 수행 후 실 객체의 실행을 제어 한다. 실 객체와 동일한 인터페이스를 구현 및 상속 해야 하므로 여러 종류의 프록시가 필요한 경우 클래스가 많아질 수 있다.

    (구조패턴) 플라이웨이트 패턴

    사용 시점 및 이유 비슷한 객체를 많이 생성하여 메모리가 부족할 때 그 객체들이 여러 중복된 필드(상태)를 포함하고 있으며, 이 상태만을 추출한 객체를 공유해도 상관 없을 때 구현 Client는 팩토리를 통해서만 플라이웨이트 객체를 받아 사용한다. 플라이웨이트 구현체는 여러 다른 로직에서 공유해도 상관없는 (불변이면 더 안전) 필드만을 가지고 있는다. 변경해야 할 상태값 같은 것들은 메소드의 파라미터로 받는 등의 방법으로 구현한다. ex) Tree 클래스는 잎의 색깔, 잎의 수 등 을 가지고 있고, 심어져야 할 x, y 좌표 등은 메소드로 받아 구현한다.

    (구조패턴) 퍼사드 패턴

    사용 시점 및 이유 복잡한 하위 로직에 대해 제한적이고, 간단한 인터페이스가 필요할 때 하위 시스템들을 계층적으로 구성할 때 추상 개념에 대한 구현 클래스와 클라이언트 사이의 결합도를 줄일 때 패턴 구현 클라이언트는 퍼사드를 통해서 기능을 실행한다. 퍼사드를 통해 인터페이스를 클라이언트에게 제공하므로, 작은 단위로 서브시스템을 구성할 수 있다. 서브시스템은 또 하나의 퍼사드일 수 있다.

    (구조패턴) 컴포지트(복합체) 패턴

    사용 시점 및 이유 개별 객체와 그 객체들을 담는 그릇들을 동일하게 취급하고 싶을 때 사용 객체들을 계층구조로 다루고 싶을 때 사용 패턴 구현 개별 객체인 Leaf와 그 그룹인 Composite는 동일하게 Component를 구현 한다. Leaf에 필요 없는 add, remove, getChild 들은 유도리 있게 잘 처리 해야 한다.(Composite 또한 마찬가지) 필요 없는 메소드까지 구현해야 하는 단점이 발생한다.

    (구조패턴) 데코레이터 패턴

    사용 시점 및 이유 어떤 클래스를 변경 없이 특정 기능을 추가하고 싶을 때 기능 확장에 있어 상속을 사용할 경우 클래스가 너무 많이 생길 때 상속보다 설계에 융통성을 부여하고 싶을 때 (상속은 컴파일 타임에 기능확장에 대해 클래스로 정의가 되나, 데코레이터 패턴을 사용하면 런타임에 가능) 패턴 구현 Decorator 추상 클래스와 꾸밈을 받을 본체인 ConcreteComponent는 동일한 Component를 구현 한다. Decorator는 Component를 가질 수 있으므로, 본체인 ConcreteComponent일 수도 있고, 그 ConcreteComponent를 가진 ConcreteDecorator일 수도 있다. Decorator로 감싸는 식으로 기능을 확장 한다.

    (구조패턴) 브릿지패턴

    사용 시점 및 구현 추상적 개념과 상세 구현의 종속관계를 피하고 싶을 때 세부 구현을 사용자에게 숨기고 싶을 때 추상적 개념과 상세 구현을 독립적으로 확장하고 싶을 때 패턴 구현 client 는 추상적 개념(Abstraction)을 통해 로직을 실행한다. Abstraction의 구현체 RefinedAbstraction은 멤버인 Implementation의 메소드들을 이용해 원하는 로직을 구현한다.

    (구조패턴) 어댑터패턴

    사용 시점 및 이유 기존 클래스를 사용하고 싶은데 인터페이스가 맞지 않을 때 새로운 클래스를 기존 인터페이스에 맞추고 싶을 때 패턴 구현 Target Interface에 Adaptee 를 맞추기 위해 Adapter에서 멤버 필드로 Adaptee를 가진다. targetMethod() 실행시 Adaptee클래스에서 해야 할 행동을 구현해 준다.

    (생성패턴) 프로토타입 패턴

    사용 시점 및 이유 인스턴스의 생성과 값 초기화가 복잡할때 반복되는 생성과 초기화 코드가 많아질 때 패턴 구현 clone()을 지원할 클래스는 Prototype인터페이스를 구현한다. 구상 클래스에서는 clone() 을 오버라이딩 하며 return new ConcreteProtoType1(this) 와 같이 구현한다. 필요한 경우 프로토타입 사용할 구상 인스턴스들을 미리 저장소에 저장해둔 후, 클론하며 사용하는 방식으로도 구현이 가능하다. 자바의 경우 이미 Cloneable인터페이스와, Object.clone() 메소드가 존재한다.