디자인 패턴 (작업중...)

0. 인터페이스

ㆍ기능에 대한 선언과 구현 분리

ㆍ기능을 사용하는 통로

인터페이스는 메서드의 선언만 하며, 상세한 구현은 클래스에서 한다.

여기서 예를 들어 보자. 이 밑으로 패턴에 대해서 설명할 때 다음과 같이 설명할 것이다.

I. 개요 : 패턴에 대한 한줄 설명

II. 원인 : 패턴이 등장한 이유를 설명

III. 특징 : 패턴의 장점 등을 설명

이 위 3줄 자체는 패턴에 대한 설명이 될 수 없다. 구체적인 내용이 없기 때문이다. 하지만, 이 아래로, 패턴에 관해 설명할 때 I. II. III.들을 각 패턴에 맞게 적어야한다. 이 때, 인터페이스를 기반으로 클래스를 통해 구현하는 것이 된다.

1. 생성 패턴 (추상 객체 인스턴스화)

1) Factory Method

I. 개요 : 상위 클래스와 하위 클래스가 있을 때, Factory를 사용하여 하위 클래스의 인스턴스를 생성한다.

II. 원인 : 조건에 따라 객체가 달라질 때, 사용자가 직접 객체 생성을 하는 것이 아닌 Factory Class에 위임하여 객체를 생성하도록 한다.

III. 특징 :

ㆍ객체를 만들어 반환하는 함수를 (생성자 대신) 제공하여 초기화 과정을 외부에서 보지 못하게 숨기고 반환 타입을 제어한다.

ㆍ사용자가 조건을 인자로 넘겨주면 해당 조건에 맞는 class를 Object로 생성해 반환한다.

ㆍ

2) Abstract Factory Method

기본 Factory를 abstract class나 Interface로 만들고, class는 abstract factory를 extends/implements하여 concrete factory 에서 만든다.

간단하게 abstract class와 interface를 위한 factory?

3) Prototype Pattern

Original object를 복사하여 새로운 object를 만들고, 적절한 수정을 가해 사용한다.

4) Singleton Pattern

Class의 Object가 하나만 존재해야할 때 사용한다. 이 때, 생성자는 private의 접근제한자를 통하여 제한한다.

5) Builder Pattern

Instance를 생성자를 통해 직접 생성하지 않고, Builder라는 내부 Class를 통해 간접적으로 생성하게 한다.

사용 목적은 크게 두가지로 나뉜다.

ㆍ클래스와 사용 대상의 결합도를 낮추기 위해 :

예를 들어, 클래스에 인수를 새로 추가하려고 하는 경우, Builder를 통하지 않으면, 해당 class를 생성하는 모든 생성자를 검색하여 인수를 추가해줘야지만, Builder를 통하면 default 값이나 set으로 간편하게 수정가능하다.

ㆍ클래스 생성할 때, 인수로 넘겨주면 각 인수의 정확한 의미를 알기어려우나 Builder의 set 함수로 설정해줌으로서 인수가 가지는 의미를 파악할 수 있다.

참고 : 빌더 패턴(Builder Pattern) - 기계인간 John Grib

Java외에서는 Factory와 Builder는 동일한 의미로 쓰인다고 한다.

2. 구조 패턴 (객체 결합)

1) Adapter

한 Class의 Interface를 사용자가 기대한 Interface 형태로 변환한다. Adapter를 통해 Interface 호환성 문제 때문에 같이 쓸 수 없는 Class를 결합하여 쓸 수 있다.

2) Decorator

객체에 동적으로 새로운 책임을 추가할 수 있게 한다. 서브 클래스를 생성하는 것보다 융통성 있는 방법이다.

가벼운 기능을 덧붙이고 싶을 때 사용하나?

3) Composite

포함하는 것과 포함되는 것들(전체-부분 관계)을 같은 방식으로 다루고 싶을 때 사용한다. 전체와 부분을 구분하지 않고 동일한 인터페이스를 사용할 수 있다. 이에 따라 이들은 트리 구조로 구성된다.

예) File과 Folder 에 대해 getSize()나 remove()등을 실행시키는 경우

4) Facade

복잡한 호출과정을 대신해주는 wrapper 객체를 따로 만드는 것.

3. 행위 패턴 (객체 간 커뮤니케이션)

1) Strategy Pattern

여러 알고리즘을 하나의 추상적인 접근점을 만들어 접근 점에서 서로 교환 가능하도록 하는 패턴.

모드마다의 동작 하나하나를 모듈로 따로 분리해서, 실행될 때마다 모듈을 갈아끼우는 형식.

클래스의 옵션에 따라서 수행되어야할 공통 동작이 조금씩 다를 때, Interface에 abstract method를 선언하고, Interface를 implement하는 class를 선언하여 세부 사항을 class 안에서 구현한다.

행동들을 모듈화하여 독립적이고 상호 교체 가능하게 만든 것.

2) 템플릿 메소드

객체의 연산에는 알고리즘의 뼈대만 정의하고 각 단계에서 수행할 구체적 처리는 서브클래스에서 담당한다. 이 패턴은 가능한 사용을 최소화해야하는데, 기반 클래스가 매우 깨지기 쉽기 때문이다.

예를 들어 템플릿 메소드가 순서대로 '+' 'x' '+' 로 구성되어있었는데, 마지막에 '-' 를 추가해야 된다면, 전체 구조가 깨져버려서 다시 프로그래밍해야한다.

3) Mediator

모든 class 간 복잡한 로직(상호작용)을 캡슐화하여 하나의 클래스에 위임하여 처리하는 패턴이다.

즉, M:N의 관계에서 M:1의 관계로 복잡도를 떨어뜨려 유지 보수 및 재사용의 확장성에 유리한 패턴이다. (개인적으로 M:N을 M:1:N 으로 만들어주는 느낌이다.)

4) Observer

객체 사이에 일대다의 의존 관계를 정의해 두어, 어떤 객체의 상태가 변할 때 그 객체에 의존성을 가진 다른 객체들이 그 변화를 통지받고 자동으로 갱신될 수 있게 만든다.

※ Mediator vs Observer

Observer 는 1개의 Publisher에 대해 N개의 Subscriber가 존재하지만, Mediator의 경우, M개의 Publisher와 N개의 Subscriber가 존재한다. 즉, M개의 Publisher가 서로서로 상태를 관찰하기 때문에 Publisher가 Subscriber가 될 수도, Subscriber가 Publisher가 될 수도 있다.

5) Proxy

연산을 하 때, 객체 스스로가 처리하지 않고 중간에 다른 숨겨진 객체를 통해 처리하는 방법.

흐름제어만 할 뿐, 결과값을 조작하거나 변경시키면 안된다.

ㆍ원래 하려던 기능을 수행하며, 그외의 부가적인 작업(로그인, 인증, 네트워크 통신) 등을 수행하기에 좋다.

ㆍ비용이 많이 드는 연산 (DB 쿼리, 대용량 텍스트 파일 등)을 실제로 필요한 시점에 수행할 수 있다. (필요하지도 않는데 비용이 많이 드는 연산을 해버리는 것을 피하기 위해서)

ㆍ사용자 입장에서는 프록시 객체든 실제 객체는 사용법은 유사하므로 사용성이 좋다.

6) State

객체가 특정 상태(State)에 따라 행위를 달리하는 상황에서 자신이 직접 상태를 체크하여 상태에 따른 행위를 호출하지 않고, 상태를 객체화하여 상태 자신이 행동을 취할 수 있도록 위임하는 패턴.

※ Strategy vs State

Strategy는 상속을 대체하려는 목적으로, State 는 코드 내의 조건문들을 대체하려는 목적으로 사용된다.

7) Command

실행될 기능들을 객체로 캡슐화한 것. 매개변수를 사용하여 여러가지 다른 요구 사항을 집어넣을 수 있다. 혹은 요청 내역을 큐에 저장하거나 로그로 기록할 수 있으며, 작업 취소도 지원가능하다. Command를 사용하면 execute() 메소드 하나만으로도 원하는 요구사항 전체를 실행가능하다.

※ Strategy vs State vs Command

ㆍStrategy : 알고리즘 자체를 클래스화해서 사용

ㆍState : 상태 그 자체를 클래스화해서 사용

ㆍCommand : 명령 그 자체를 클래스화해서 사용

후기 ::

왜 디자인 패턴, 디자인 패턴하나 했는데 공부하고 나니 어디서 봤던 패턴들도 있고, 무의식적으로 써왔던 것도 있고, 막연하게 '이런 식으로 구현하면 편하지 않을까?' 하던 것도 있는거 보니 역시 사람들 생각은 다 비슷한가보다.

디자인 패턴을 모르고 실무에 들어가면 클나겠다 싶다. 마치 동 이름도 모르는 경찰관이 된 듯한 기분이 아닐까? 서로 소통하기가 매우 힘들 것 같다. 그러니 열심히 공부해야지.

OOP를 제대로 설계하고 구현하는 것은 힘들겠지만, 엄청 재미있을 것 같다. 그리고 예제가 99% Java이던데 Java도 한번 배워보고 싶다. 연습삼아 DropTheBit를 OOP로 구현해봐도 재밌을 것 같고. (지금 어느정도 OOP를 쓰긴하지만..)

참고

[디자인패턴] 전략 패턴 ( Strategy Pattern ) :: victolee (tistory.com)

객체지향 디자인 패턴 1 | 얄코 (yalco.kr)

추상 팩토리 패턴 (Abstract Factory Pattern) - 기계인간 John Grib