디자인 패턴

디자인 패턴이란? 

디자인 패턴은 아키텍쳐 패턴에서 좀 더 하위로 내려와서 비슷한 개념을
수행하는 것을 말합니다.
 
아키텍쳐 패턴이나 디자인 패턴이나 마찬가지로
구체적인 작업을 만들거나 수행하기 전에 큰 윤곽을 잡는 것이라고 생각하면 됩니다.
 
 

둘 간의 차이점.

  아키텍쳐가 전체 시스템의 구조를 설계하는 것이라면,
  디자인 패턴은 서브시스템과 모듈들 사이의 관계를 설계하는 것입니다.
 
  디자인 패턴이 좀 더 하위고 구체적이지만,
  실제 구체적인 동작을 설계하는 것은 아니고,
  구체화를 어떻게 할 것인지를 설계한다고 생각하면 됩니다.
 
 
""

디자인 패턴이 생긴 이유.
원하는 방향성과 큰 틀을 잡지 않고 하나하나 만들기 시작하는 것은,
어떤 산이 바위와 나무없이 흙과 잔디로만 채워지는 것과 비슷합니다.
아주아주 비생산적입니다.
그러지 않기 위해
생산성을 높이기 위한 많은 시행착오들이 있었고,
그 결과로, 생산성을 높일 수 있게끔 설계되고,
많이 쓰이는 공통의 패턴들을 정리해서 분류한 것입니다.

""
 
 

디자인 패턴의 구성.

  문제 및 배경 : 이 패턴이 필요하게 된 계기, 이 패턴을 사용하지 않으면 발생하는 문제, 단점.
 
  실제 적용된 사례 : 이 패턴을 실제로 사용해서 바뀐 긍정적인 사례.
 
  재사용이 가능한 샘플 코드 : 이 패턴을 따라 구현하기 위한 쉽고 간단한 예제 코드.
 
 
 
 

디자인 패턴의 장.단점.

  범용성이 뛰어나 구조파악이 쉽다.
 
  객체지향 기반 설계 및 구현의 생산성 향상에 유리하다.
 
  사례를 기반한 검증된 구조로써 개발 시간, 즉, 비용이 절약된다.

      ㄴ 허나 구조에 맞춰서 개발하기 위한 초기비용이 부담될 수 있다. -단점
           ㄴ 그렇지만 후에 변경 및 유지 보수를 한다면 장기적으론 비용이 절약된다. -장점

 
  이미 공통된 패턴을 참조하기 때문에 개발자간의 의사소통이 원활하다.
 
  객체지향 기반의 설계와 구현만을 다루기 때문에, 다른 기반의 개발엔 적합하지 않다.

디자인 패턴의 종류

  생성 패턴 : 객체의 생성이나 참조과정을 캡슐화 함으로써,
  후에 객체가 생성이나 변경되어도 프로그램에 끼치는 영향을 줄이고 유연성을 더하기 위한 패턴.

  구조 패턴 : 구조적으로 객체를 조합하여 더 복잡하고 큰 시스템을 개발하기 위한 패턴.

  행위 패턴 : 객체간의 상호작용, 책임분배 방법을 정의해서,
  하나의 객체로 수행할수 없는 것을 여러 객체로 분배해서 결합도를 최소화하기 위한 패턴.

  (객체간의 결합도가 높으면 그만큼 각 객체의 변경이 어렵다.)

 

생성 패턴 5가지

  추상 팩토리 : Abstract Factory
  인터페이스를 통해 연관된 객체를 한번에 묶어서 표현하는 것.

  빌더 : Builder
  작은 여러 객체들을 조립(빌드업)해서 하나의 건축물같은 객체를 생성.
  생성과 표현이 분리돼, 동일한 객체를 생성해도 표현을 달리해서 다른 결과 도출 가능.
  
  팩토리 메소드 : Factory Method
  공장(factory) 에서 컨베이어벨트 돌아가면서 제품 찍어내듯이,
  상위클래스에서는 인터페이스만 정의하고,
  객체 생성은 서브클래스에서 처리하게끔 분리하여 캡슐화하는 패턴.
  ( = 가상 생성자 : Virtual Constructor )
  
  프로토타입 : Prototype
  프로토타입을 참조하여 복제하는 패턴.
  하나의 객체를 또 만드는 비용이 클 때 주로 사용한다.

  싱글톤 :Singleton
  오직 하나의 객체만 생성해서, 그것을 어디서든 참조할 수 있지만, 여러 프로세스에서 동시에는 불가능.
  메모리 낭비를 줄이고, 하나뿐이기 때문에,
  하위에 참조될 객체들이 공통적으로 다 해당되는 것을 다루기 위해 쓰는 패턴.

구조 패턴 7가지

  어댑터 : Adapter
  호환이 안되는 클래스들의 인터페이스를 이용가능하게 연결해주는 패턴.
  기준이 되는 기존 객체가 있고, 새로운 것을 그것에 호환시키기 위한 패턴.
 

    쉽게 생각하면 220v인 한국의 제품을 110v인 미국에서도 쓰려고 플러그에 변압기를 끼우는 것.

  브릿지 : Bridge
  구현부에서 추상층을 분리하여, 각 층이 독립적으로 확장할 수 있게끔 구성하는 패턴.
 

    예를 들어,
    과일 - 완숙 바나나, 덜익은 바나나, 완숙 토마토, 덜익은 토마토 가 있고,
    위 기준에 의해 감을 추가하고 싶다면, 완숙 감과 덜익은 감을 둘 다 만들어야 됩니다.
    추가로 여기에 상했다는 걸 추가하고 싶으면 모든 객체를 하나씩 더 만들어야 됩니다.
    이것을 해결하기 위해,
    과일 - 종류, 숙성도 라는 그룹으로 인터페이스를 분류하면,
    원하는 옵션이 생길때마다 각 그룹에 하나만 추가하면 됩니다.
    이렇게 다른 역할을 의미하는 그룹끼리 짝지어 독립적으로 확장하게끔 하는 패턴이 브릿지 패턴입니다.

 
  컴포지트 : Composite
  복합물 이라는 뜻.
  복잡한 트리구조 형태를 가진 객체와 단일 객체를 구분없이 다루고자 할 때 사용하는 패턴.
 

    큰 나뭇가지에 난 모든 잔가지들과 잎을 뚝 뗀 것이든, 잔 나뭇가지 하나만 뗀 것이든 둘 다 하나처럼 다루고,
    각 복합물 안에 복합물을 포함시키는 구조도 구현할 수 있다.

  데코레이터 : Decorator
  데코한다는 뜻과 동일하게, 기존 객체에 추가적으로 기능을 더하기 위한 패턴. 덧붙이는 방식.

  퍼싸드 : Facade
  건축에서 건물의 외관을 의미.
  복잡한 구조를 Wrapper 객체로 감싸고 상위에 인터페이스를 구성해서,
  하위 구조물들을 편리하게 사용하기 위한 패턴.

  플라이웨이트 : FlyWeight
  단어 뜻 그대로, 성능이 가벼운 프로그램을 위해 비슷한 객체들을 공유함으로써,
  유사 객체의 과다 생성을 방지하기 위한 패턴.

  프록시 : Proxy
  대리 라는 뜻으로, 접근이 어려운(다루기 어려운) 객체와 이것에 연결하려는 객체 사이에서
  인터페이스의 역할을 수행하는 패턴.
  네트워크 연결, 메모리의 대용량 객체로의 접근 등에 주로 이용.
 
 

행위 패턴 11가지

  책임 연쇄 : Chain of Responsibility
  요청을 처리할 수 있는 객체가 여럿 존재하고, 이전 객체가 못하면 다음 객체에게 계속 떠넘기는 패턴.
  객체끼리 책임이 체인 고리(Chain) 처럼 연결됐다는 의미.

  커맨드 : Command
  커맨드 즉, 요청의 형태를 객체로써 저장해놨다가, 재이용하거나 취소할 때 그것을 참조하는 패턴.
  요청에 사용되는 명령어들을 추상 및 구체 클래스로 분리해서 단순화 시킴.
  커맨드 센터의 역할이라고 보면 됨.
 

    여러 요청을 한 커맨드에 전부 저장하면 상위에서는 커맨드에서 전달받으면 되고,
    하위에서는 적절한 상위 클래스를 찾을 필요 없이, 커맨드에 전달하면 됨.
    예를 들어,
    중식당에 가서 짜장면을 주문하면 주방장은 짜장면의 자세한 정보를 받지 않아도
    알아서 만들어서 나온다. 주문은 요청을 보낸것이고, 주방장의 머릿속이 커맨드 센터이고,
    실제 요리를 만든 행위는 구체 클래스 인셈.

  인터프리터 : Interperter
  번역가라는 뜻 그대로,
  언어의 문법을 표현하는 방법을 정의하는 패턴.
 

    SQL 이나 통신 프로토콜 개발에 쓰임.
    또는 간단한 수식을 해석하는데 쓰일 수도 있음.
    예를 들어, 더하기 빼기를 곱하기 나누기를 전부 클래스로 정의한뒤
    계산기를 만들 때 정의된 클래스를 호출해서 복잡한 정의를 간단한 수식으로써 사용할 수 있다.

  반복자 : Iterator
  자료 구조나 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴.
  내부 표현 방법의 노출 없이 순차적인 접근이 가능.
 

    반복 호출될 객체들을 인터페이스로 연결하고,
    클래스들끼리 필요한 작업을 알아서 수행하게끔 구성한 뒤,
    객체를 생성하고 값만 넣어주면 모든 객체의 값에 접근할 수 있는 패턴.

 
  중재자 : Mediator
  단어 뜻 그대로, 객체들 간에서 통제와 지시를 하는 패턴.
  다수의 객체 간의 복잡한 상호작용 사이에서,
  캡슐화를 통해서 객체 사이의 의존성을 줄이는 패턴.
    

    비행기끼리 통신하지 않고 관제탑을 통해서 통신하는 것이나,
    도로 위에 교통경찰이 정리 해주는 것과 같은 개념.

  메멘토 : Memento
  특정 시점의 객체 상태를 객체화함으로써 이후 요청에서 해당 시점을 불러내면
  되돌릴 수 있는 기능을 제공하는 패턴. Ctrl+Z 같은 기능을 개발할 때 쓰임.
 

    프랑스어 (mement : 추억) 으로 기억하면 편하다.

  옵저버 : Observer
  관찰자 라는 뜻과 같이, 계속 주시하고 있다가,
  한 객체의 상태가 변화하면, 상속된 다른 객체들에게 상태를 전달하는 패턴.
  주로 분산 시스템 간에 이벤트 생성 및 발행, 수신에 쓰임.
 

    원치 않은 이벤트를 무조건 수신하는것이나,
    이벤트를 수신하기 위해 계속 확인하는 것은 비효율적이므로,
    두가지 행위 사이에서 구독된 객체에만 이벤트 발생을 알리는 것.
 

  상태 : State
  객체의 상태에 따라 동작을 다르게 처리할 때 사용하는 패턴.

   
    상태가 행동을 결정하기 때문에, Switch 문 같은 개념으로 이해하면 좋다.

  전략 : Strategy
  여러 전략(알고리즘을 가진 객체)들을 캡슐화해 상호교환할 수 있게 정의하는 패턴.
  콘텍스트 라는 상위 클래스 또는 원래 클래스가 있고,
  거기에 전략중 하나를 선택해서 실행을 위임한다.
 

    비슷한 개념을 생각해보면, 객체들을 배열화 하고, 그 중 조건에 맞는 인덱스의 메소드를 실행하는 개념과 유사.
    상태 패턴과의 차이점은, 전략은 객체를 완전히 독립적으로 구분해 각 알고리즘 간 아예 간섭을 못하는 반면,
    상태 패턴은 상태객체 간의 의존성을 제한하지 않음.

  템플릿 메소드 : Template Method
  템플릿은 '틀' 이라는 뜻으로 이해하면 되고,
  템플릿 메소드는 상위 클래스에서는 틀만 정의하고, 하위 클래스에서 세부 처리 구체화를 하는 패턴.
  유사한 하위 클래스들끼리는  공통된 내용을 묶어 상위 클래스에 정의함으로써
  코드의 양을 줄이고 유지보수를 용이하게 함.

  방문자 : Visitor
  이미 완성되어 수정이 힘들거나, 수정시 오류가 날 수 있는 프로그램에 기능을 추가하기 위해,
  방문자 자신이 모든 객체들의 정보를 가지고 객체에 방문해서 정보를 얻어오는 패턴.
  원래 객체는 방문자를 받아들이는 것만 수행하면 되고,
  또 다른 객체가 추가되면 방문자를 새로 업데이트 해야함.