bridge pattern : 기능의 계층과 구현의 계층을 분리한다

'기능의 클래스 계층' 과 '구현의 클래스 계층' 사이에 다리를 놓는다.

클래스 계층의 두 가지 역할

• 새로운 '기능'을 추가하고 싶을 때

something

|

----- somethingGood

|

------- somethingBetter

새로운 기능을 추가하고 싶을 때 클래스 계층 안에서 새로 만들려고 하는 클래스와 유사한 클래스를

찾아내 하위 클래스를 만들어 기능을 추가

ps. 일반적으로 클래스 계층은 너무 깊게 하지 않는 것이 좋다

• 새로운 '구현'을 추가하고 싶을 때

AbstractClass

  |

  ------ ConcreateClass

|

-------- AnotherConcreateClass

두개로 클래스 계층을 나눠두면 각각의 클래스 계층을 독립적으로 확장할 수 있다

기능을 추가하고 싶으면 기능의 클래스 계층에 클래스를 추가한다

이때 구현의 클래스 계층은 전혀 수정하지 않아도 된다. 게다가 새로 추가한 기능은 '모든 구현'에서 이용 할 수 있다

상속은 견고한 연결, 위임은 느슨한 연결

장점  

구현을 인터페이스에 완전히 결합시키지 않았기 때문에 구현과 추상화된 부분을 분리시킬 수 있다.

추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있다

추상화된 부분을 구현한 구상 클래스를 바꿔도 클라이언트 쪽에는 영향을 끼치지 않는다

활용법 및 단점

추상과 구현이 한 클래스에 같이 붙어있지 않고 그들을 분리하여 확장을 쉽게 하고 싶을 때 사용한다.

그 결과 추상과 구현이 분리되어 결합도가 낮아진다.

추상은 그대로 두고 구현만 프로그램  실행중에 변경해도 다른 클라이언트에게 영향을 미치지 않게 할 경우에 적용한다.

여러 플랫폼에서 사용해야 할 그래픽스 및 윈도우 처리 시스템에서 유용하게 쓰인다

인터페이스와 실제 구현부를 서로 다른 방식으로 변경해야 하는 경우에 유용하게 쓰인다

디자인이 복잡해진다는 단점

Adapter pattern   : 필요한 형태로 수정해서 재활용한다

 = Wrapper pattern

무언가를 싸서 다른 용도로 사용할 수 있도록 교환해 주는 것

•  클래스에 의한 Adapter pattern(상속을 이용)
•  인스턴스에 의한 Adapter pattern(위임을 이용)

Adapter pattern은 기존의 클래스를 수정해서 필요한 클래스로 만든다. 이 패턴에 의해

필요한 메소드를 재빨리 만들 수 있다. 만약 버그가 발생하더라도 기존의 클래스에는

버그가 없기 때문에 Adapter 역할의 클래스를 중점적으로 조사만 하면 되니깐 프로그램 체크가

아주 간편해진다

버전과 호환성

소프트웨어를 버전업할때 문제가 되는 것이 '기존 버전과의 호환성'이다

기존 버전을 버리면 소프트웨어의 보수는 간단하지만 항상 그것이 가능하다고는 할 수 없다

기존 버전과 새로운 버전을 공존시키고 보수를 간단하게 하는데 Adapter pattern이 도움이 되는 경우가 있다

예제)

구식 Enumeration과 신형 Iterator의 결합

public class EnumerationIterator implements Iterator

{

Enumeration enum;

public EnumerationIterator(Enumeration eunm){

this.enum = enum;

}

public boolean hasNext(){

return enum.hasMoreElements();

}

public Object next(){

return enum.nextElement();

}

public void remove(){

throw new UnsupportedOperationException();

}

}

Adapter pattern은 겉보기에 Bridge와 비슷해 보인다. 하지만 Adapter pattern은 어떤 클래스의 인터페이스가 다른 코드에서 기대하는 것과 다를때 어댑터를

중간에 두어서 맞춰주는 것이고, Bridge는 추상과 구현을 분리하는 것으로 그 의미가 명백히 구별된다.

 Mediator : 상대는 하나뿐

 mediator : 조정자, 중개자

다수의 객체를 조정해야 하는 경우에 사용

서로 관련된 객체 사이의 복잡한 통신과 제어를 한 곳으로 집중시키고자 하는 경우에 사용

서로 협력해야 하는 여러 객체들의 "중재자"가 존재하여 그들이 서로를 알지 못하더라도 다른 객체에 메시지를 보내고 받을 수 있다.

미디에이터를 사용하면,,

상태가 바뀔 때마다 미디에이터한테 알려주고, 미디에이터에서 보낸 요청에 응답을 한다

미디에이터를 추가하기 전에는 모든 객체들이 다른 객체들하고 서로 알고 있어야 했다

서로 밀접하게 연관되어 있었지만 미디에이터를 사용한 후로는 서로 완전히 분리될 수 있다.

미디에이터에는 모든 시스템을 제어할 수 있는 로직이 들어있다. 새로운 규칙을 추가해야 한다거나

새로운 시스템에 추가하더라도 미디에이터만 고치면 된다.

장점

시스템하고 각 객체를 분리시킴으로써 재사용성을 획기적으로 향상시킬 수 있다

제어 로직을 한 군데 모아놨기 때문에 관리하기가 수월하다

시스템에 들어있는 객체 사이에서 오가는 메시지의 종류를 확 줄이고 단순화시킬 수 있다

활용법 및 단점

서로 연관된 GUI 구성요소들을 관리하기 위한 용도로 많이 쓰인다

디자인을 잘 하지 못하면 미디에이터 객체 자체가 너무 복잡해 질 수 있다.

"중재자" 클래스에 모든 객체들에 대한 컨트롤이 집중되기 때문에 프로그램이 규모가 커질수록 이해하기 힘들어진다.

Facade 패턴과의 관계

Facade 패턴은 서브 시스템을 상징하는 클래스(Facade 클래스)를 통해 서브 시스템 내부의 클래스들의 존재를 모른 상태에서 그 기능을

사용하게 해준다. 서브 시스템내의 클래스는 Facade 클래스의 존재를 모른다. 하지만,

Mediator 패턴은 모든 협력 클래스들은 중재자(Mediator) 클래스의 존재를 알아야 한다.

/***************************************

***** Design Pattern 정리 - flyburi.com 버리  ****

/***************************************

***** Design Pattern 정리 - flyburi.com 버리****

***************************************/

State Pattern - Design Pattern

Problem

1. How can you change the class of an object at run-time?

2. How can you model a finite state machine using OO techniques?

Example 1.

스타크래프트에서 플레이어가 테란 유닛들 중에서 마린, 벌처, 탱크에게 임의의 공격명령을 내렸을 때 자신의 상태에 따라 행위가 달라질 때 적용가능?

공격(abstract class) 이라는 하나의 공통적인 행위안에 세가지 또는 그 이상의 상태를 나타낼수 있습니다.

마린공격, 벌처공격, 탱크공격 - ConcreteState마린, ...

마린은 총을 쏠것이고, 벌처는 마인을 박거나 던지기, 탱크는 퉁퉁때리기와 시즈모드에서 공격하는것. 자신의 상태에 따라 공격하는 행위가 달라지는데 이럴때 적용가능할 것 같은데.. 맞나요? ^^;;

Example 2.

은행사이트에서 시간의 변화에 따라 (이체 이용시간) 서비스가 허용되는 상태

Example 3.

The State pattern allows an object to change its behavior when its internal state changes. This pattern can be observed in a vending machine. Vending machines have states based on the inventory, amount of currency deposited, the ability to make change, the item selected, etc. When currency is deposited and a selection is made, a vending machine will either deliver a product and no change, deliver a product and change, deliver no product due to insufficient currency on deposit, or deliver no product due to inventory depletion. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54

State Pattern은 이렇다.

객체의 행위가 별도로 분리된 상태(state)에 따라 달라지도록 해준다.

이때 상태 정보는 클래스로 정의된다.

상태의 정보를 캡슐화하여 프로그램 실행 중에 특정 객체의 행위를 변경하는 패턴

더 참고할 URL

충북대학교에서 번역한 자료

Using the STATE Design Pattern in Java(예제)

Strategy Pattern

Strategy Pattern은 이렇다.

알고리즘군의 교체

동일 목적 알고리즘의 선택 적용 문제

프로그램 작성하다가 한가지 작업을 수행하는데 사용할 수 있는 알고리즘이 여러개 존재하는 경우

적용시기와 효과가 비슷하게 보이는 State Pattern과 Strategy Pattern의 차이점

State Pattern은 상태에 따라 행위가 달라지지만, Strategy Pattern은 동일한 결과에 과정을 다르게 교체하여 도출한다.

1) 서브클래스의 코드 중복
  부모클래스에서 메소드 fly()를 구현해 놓았다면(abstract일때) 서브 클래스에서는
  fly()를 쓰지 않아야 할때 매번 안쓴다는 코드를 구현해야 한다.
  (불필요한 행동을 그냥 아무것도 하지 않는것으로 오버라이드 해야한다.
  만약 규격이 자주 바뀌게 되면 매번 프로그램에 추가했던 부모클래스를 상속받은
  서브클래스의 메소드를 모두 일일이 살펴봐야한다.)

2) 실행시에 특징을 바꾸기 힘들다.

3) 모든 행동을 알기 힘들다.

4) 코드를 변경했을 때 다른 클래스에 원치 않은 영향을 끼칠수 있다.

덧 - “인터페이스”를 이용해 프로그램을 할때의 단점
자바 인터페이스에는 구현된 코드가 전혀 들어가지 않기 때문에 코드 재사용을 할 수 없다는 문제점이 있다. 즉 한 행동을 바꿀 때마다 그 행동이 정의되어 있는 서로 다른 서브클래스들을 전부 찾아서 코드를 일일이 고쳐야 하고, 그 과정에서 새로운 버그가 생길 가능성이 있다.

덧 - Interface와 Abstract Class
Interface는 구현된 Method가 없다. 모두 선언만 되어 있다.
Abstract Class는 일부분 구현된 Method가 있고 추상 Method는 하나 이상 있어야 하고 일반 Method도 있을수 있다.

디자인패턴 Point
소프트웨어를 만들 때, 나중에 혹시 고쳐야 할 때도 기존 코드에 미치는 영향은 최소한으로 줄이면서 작업을 할 수 있도록 만들수 있는 방법이 있다면 정말 행복하지 않을까?

디자인원칙
1. 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다.
달라지는 부분을 찾아서 나머지 코드에 영향을 주지 않도록 “캡슐화”한다.
그렇게 하면 나중에 바뀌지 않는 부분에는 영향을 미치지 않은채로 그 부분만 고치거나 확장할 수 있다.

2. 구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.
상위(추상Class나 interface) 형식에 맞춰 프로그래밍한다.
실제 실행시에 쓰는 객체가 코드에 의해서 고정되지 않도록, 어떤 상위 형식(supertype)에 맞춰서 프로그래밍함으로써 다형성을 활용해야 한다.

더 바람직한 방법
new Dog() 같은 식으로 직접 코드를 만드는 대신 구체적으로 구현된 객체를 실행시에 대입하는 것.
A = getAnimal();
a.makeSound();

3. 상속보다는 구성을 활용한다.
구성 : “A는 B이다” 보다는 “A에는 B가 있다”가 나을수 있다.
“A에는 B가 있다” 관계에 대해 생각해 보면 각 오리에는 FlyBehavior와 QuackBehavior가 있으며, 각각 행동과 꽥꽥 거리는 행동을 위임 받는다
두 클래스를 이런식으로 합치는 것을 구성(composition)을 이용하는 것이라고 부른다.

한번 Think! 해보기
동적으로 행동을 지정하는 방법
상속과 interface를 통해 “동적”으로 코드를 쓰는 방법을 해결하는 방식 연구하기

- Head First Design Pattern을 공부하며

나만의 Think! 공감 안하면 말구~

디자인패턴을 시작하며,
현업 SI에서는 아주 PM이 유능해서 업무가 밀린다거나, 전혀 애로사항이 없다면 몰라도,
요구정의와 분석, 설계하는데 많은 부분이 프로젝트 기간중에 소요가 된다.
막상 개발자들은 실제 코딩을 하는 기간은 매우 짧다.
개발자들이 무슨 죄가 있는지, 프로젝트 오픈일이 다가 올수록 개발자가 못해서 프로젝트가 길어지는양, 위에서는 억압(?)을 하며 마감일 엄수를 외친다.

PM의 심정을 모르는것도 아니고, PL의 심정을 모르는 것도 아니겠지만,
개발기간이 짧아 무조건 우선 코드의 생김새보다는, 돌아가게끔만이라도 해야할 때가 있다.
이럴 때 언제 패턴을 따지며, 프로그램을 짤수있을까? 란 의문이 항상 든다.

하지만, 이렇게 생각하는 사람이 나혼자 있는 것이 아니고, 내 위의 선배들도 모두 생각하는 일이고, 오래전부터 언급되어 왔으니, 환경이 점차 나아지리라 희망을 건다.
소스의 효율성과 유지보수시의 편리함까지 생각할 수 있을 때,
그때 패턴을 적용할 날이 오겠지.
그날을 기다리며 패턴의 종류와 각각의 이점을 알아두는 개발자들이 늘어야 할 것이다.

아직 먼나라 얘기같지만,
그때 이 패턴을 적용해 이렇게 이렇게 코드를 짜자. 라고 말했을 때
알아들을수 있고, 적용할 수 있는 개발자들이 많아지기를 바랄뿐이다.
물론, 나도 그중의 한사람으로서..
디자인 패턴은 개발자들 사이에서 모두 이해할 수 있는 용어들을 제공하는 역할을 한다.
일단 용어를 이해하고 나면 다른 개발자와 더 쉽게 대화할 수 있고, 의사소통을 하기가 쉬워진다.