디자인 패턴에 대하여(feat. 브리지 패턴)

디자인 패턴이란?

디자인 패턴이란 프로그래밍 할때에 문제를 해결하고자 코드의 구조들을 일정한 형태로 만들어 재이용하기 편리하게 만든 일정한 패턴. 재사용할 경우 굉장히 유용하게 만든 패턴이다.

디자인 패턴의 종류?

1. 생성패턴
   –Abstract Factory (추상 팩토리)
   -동일한 주제의 다른 팩토리를 묶어 준다.
   –Builder
   -생성(construction)과 표기(representation)를 분리해 복잡한 객체를 생성한다
   –Factory Method
   -생성할 객체의 클래스를 국한하지 않고 객체를 생성한다.
   –Prototype (원형)
   -기존 객체를 복제함으로써 객체를 생성한다.
   –Singleton (단일체)
   -한 클래스에 한 객체만 존재하도록 제한한다.
2. 구조패턴
   –Adapter (적응자)
   -인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록, 타 클래스의 인터페이스를 기존 인터페이스에 덧씌운다.
   –Bridge (가교)
   -추상화와 구현을 분리해 둘을 각각 따로 발전시킬 수 있다.
   –Composite (복합체)

• 0개, 1개 혹은 그 이상의 객체를 묶어 하나의 객체로 이용할 수 있다.
  –Decorator (장식자)
  -기존 객체의 매서드에 새로운 행동을 추가하거나 오버라이드 할 수 있다.
  –Façade (퍼사드)
  -많은 분량의 코드에 접근할 수 있는 단순한 인터페이스를 제공한다.
  –Flyweight (플라이급)
  -다수의 유사한 객체를 생성·조작하는 비용을 절감할 수 있다.
  –Proxy (프록시)
  -접근 조절, 비용 절감, 복잡도 감소를 위해 접근이 힘든 객체에 대한 대역을 제공한다.

3. 행위패턴
   –Chain of Responsibility (책임연쇄)
   -책임들이 연결되어 있어 내가 책임을 못 질 것 같으면 다음 책임자에게 자동으로 넘어가는 구조
   –Command (명령)
   -위의 명령어를 각각 구현하는 것보다는 위 그림처럼 하나의 추상 클래스에 메서드를 하나 만들고 각 명령이 들어오면 그에 맞는
   서브 클래스가 선택되어 실행하는 것
   –Interpreter (해석자)
   -문법 규칙을 클래스화한 구조를 갖는SQL 언어나 통신 프로토콜 같은 것을 개발할 때 사용
   –Iterator (반복자)
   -반복이 필요한 자료구조를 모두 동일한 인터페이스를 통해 접근할 수 있도록 메서드를 이용해 자료구조를 활용할 수 있도록 해준다.
   –Mediator (중재자)
   -클래스간의 복잡한 상호작용을 캡슐화하여 한 클래스에 위임해서 처리 하는 디자인 패턴
   –Memento (메멘토)
   -Ctrl + z 와 같은 undo 기능 개발할 때 유용한 디자인패턴. 클래스 설계 관점에서 객체의 정보를 저장
   –Observer (감시자)
   -어떤 클래스에 변화가 일어났을 때, 이를 감지하여 다른 클래스에 통보해주는 것
   –State (상태)
   -동일한 동작을 객체의 상태에 따라 다르게 처리해야 할 때 사용하는 디자인 패턴
   –Strategy (전략)
   -알고리즘 군을 정의하고 각각 하나의 클래스로 캡슐화한 다음, 필요할 때 서로 교환해서 사용할 수 있게 해준다.
   –Template Method
   -상위 클래스에서는 추상적으로 표현하고 그 구체적인 내용은 하위 클래스에서 결정되는 디자인 패턴
   –Visitor (방문자)
   -각 클래스의 데이터 구조로부터 처리 기능을 분리하여 별도의 visitor 클래스로 만들어놓고 해당 클래스의 메서드가
   각 클래스를 돌아다니며 특정 작업을 수행하도록 하는 것

자세히 살펴볼까?

하나씩 텍스트로 이해하자니 너무 어려워서 그림이 포함된 하나의 예제를 가져와보았다.
출처 : 여기

구현과 더불어 추상화까지 변경해야 한다. 이때 브릿지 패턴을 사용하기로 하였고 시나리오는 대략 이렇다.

혁신적인 ‘만능 리모컨’을 만들 예정. 인체공학적이고 사용자 친화적인 TV 리모컨에서 쓸 코드 구현. 리모컨 자체는 똑같이 추상화 부분을 바탕으로 하지만, TV 모델마다 엄청나게 많은 구현 코드를 사용해야 하므로 객체지향 기법을 활용.

리모컨은 모든 TV를 대상으로 작동해야 하다 보니 처음에는 제대로 작동하지 않을 가능성이 높음. 따라서 리모컨도 바뀔 수 있고, TV도 바뀔 수 있다는 문제 직면. 사용자 인터페이스는 이미 추상화했으므로 리모컨 사용자가 쓸 다양한 TV 종류에 따라 구상 클래스를 바꿔 쓸 수 있음. 허나 사용자들이 제공하는 정보에 맞춰서 리모컨을 개선하다 보면 추상화 부분까지도 바꿔야 할 가능성 존재. 이때 브리지 패턴을 통해 추상화된 부분과 구현 부분을 서로 다른 클래스 계층구조로 분리해서 그 둘을 모두 변경할 수 있습니다.

한쪽은 리모컨을 나타내는 부분이고 다른 쪽은 종류 별로 다른 TV를 나타내는 부분. 하지만 브리지로 연결했으므로 양쪽을 서로 독립적으로 바꿔줄 수 있음.

장점

• 구현과 인터페이스를 완전히 결합하지 않았기에 구현과 추상화 부분을 분리할 수 있습니다.

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

• 추상화 부분을 구현한 구상 클래스가 바뀌어도 클라이언트에는 영향을 끼치지 않습니다.

단점

• 여러 플랫폼에서 사용해야 하는 그래픽스와 윈도우 처리 시스템에서 유용하게 쓰입니다.

• 인터페이스와 실제 구현할 부분을 서로 다른 방식으로 변경해야 할 때 유용하게 쓰입니다.

• 디자인이 복잡해진다는 단점이 있습니다.