일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- nginx설정
- NoSQL
- 카프카
- nginx
- 레디스
- JPA
- 카프카 트랜잭션
- gcm 푸시 번역
- git
- Push
- 웹사이트성능
- Design Pattern
- Java
- GCM 번역
- 자바스크립트
- GCM
- 푸시 번역
- 디자인패턴
- 성능
- nginx설치
- 웹사이트 성능
- redis
- notification
- APNS
- php
- 페이스북 번역
- 웹사이트최적화기법
- 푸시
- kafka
Archives
- Today
- Total
간단한 개발관련 내용
Bridge Pattern 본문
반응형
Bridge Pattern
디자인 패턴 카탈로그에는...
- 구현부의 추상층을 분리하여 각자 독립적으로 변형할 수 있게 하는 패턴입니다.
디자인 패턴 영역 - 구조 및 객체 패턴.
디자인 패턴 관계도 - X.
의도 - 구현에서 추상을 분리하여, 이들을 독립적으로 다양성을 가질 수 있도록 합니다.
* 구현 뿐만 아니라 추상화된 부분까지 변경시켜야 하는 경우에 사용한다.
동기 - 상속대신 추상클래스를 사용하더라도, 추상적 개념을 구현과 분리해서 재사용,수정,확장하기 어려움이 있다. 추상적 개념을 구체적인 구현에 종속적일 필요 없이 생성할 수 있게 해야 한다. (책의 윈도우 컨셉?과 플랫폼이라 표현하고 싶다.)
활용 - 클라이언트가 구현을 모르더라도 구현에 대해 여러 가지 형태를 추상적으로 사용가능하게 한다.
1. 추상적 개념과 이에 대한 구현 사이의 지속적 종속관계를 피하고 싶을 때.
2. 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할 때.
3. 추상적 개념에 대한 구현 내용을 변경하는 것이 다른 관련 프로그램에 아무런 영향을 주지 않아야 할 때.
4. 사용자들은 사용자에게 구현을 완벽하게 은닉하길 원할 때 (private 을 사용하여).
5. 클래스 상속 계통에서 하나의 이유로 여러 개 클래스가 갑자기 정의되어야 하는 상황일 때.
6. 여러 객체들에 걸쳐구현을 공유하고자 하며, 또 이런 사실을 사용자 쪽에 공개하고 싶지 않을 때.
결과
1.인터페이스와 구현 분리.
2. 확장성 제고. (Abstraction과 Implementor 각자).
3. 구현 세부 사항을 사용자에게서 숨기기.
반응형