Search

Disign Pattern

[- Disclaimer -] 아래 내용은 정보보안 공부 목적으로 작성된 것이나, 이를 토대로 허가되지 않은 대상에 실습을 진행할 경우 해킹 시도로 간주하여 법적 처벌을 받을 수 있음을 알려 드립니다.
Disign Pattern
✦ GoF라 불리는 Erich Gamma (=에릭 감마), Richard Helm(=리차드 헬름), Ralph Johnson=(랄프 존슨), John Vlissides(=존 블리시디스)가 처음 구체화 및 체계화
✦ Trouble Shooting 시 바퀴 다시 발명하지 말고 유사한 패턴을 참고하여 적용/해결
✦ 특정 요구 사항 반영 및 Pattern 변형 시 다른 형태의 유사 Pattern으로 변화
GoF (=Gang of Four)
✦ 수 많은 Disign Pattern 중 가장 일반적인 사례에 적용될 수 있는 Pattern들로 분류
✦ 협업에서 가장 많이 사용 됨
✦ 유형에 따라 생성 Pattern 5개, 구조 Pattern 7개, 행위 Pattern 11개로 총 23개 Pattern으로 구성
Disign Pattern - 장점
✦ 범용적 Coding Style로 구조 파악 용이
✦ 객체 지향 설계 및 구현 시 생산성 향상
✦ 검증된 구조의 재사용으로 개발 시간 및 비용 감소
✦ 개발자 간 원할한 의사 소통 가능
✦ 설계 변경 요청에 유연한 대처 가능
Disign Pattern - 단점
✦ 초기 투자 비용 증가
✧ 요구 사항을 직접 구현하는게 아닌 Disign Pattern에 맞춰야 하므로 초기에만 들지, 나중에 유지 보수 및 재사용, 변경에 유연해 짐
✦ 객체 지향에만 적합
Creational Pattern (=생성 패턴)
✦ 객체의 생성 및 참조 과정을 캡슐화해 객체가 생성/변경되도 프로그램 구조에 미영향하게 하여 유연성을 증가시키는 5개의 Pattern
✦ Abstract Factory (=추상 팩토리)
✧ 구체적인 Class에 미의존
✧ Interface를 통해 연관, 의존하는 객체들을 그룹으로 생성해 추상적으로 표현한 Pattern
✧ 연관 Sub Class들 Groupping해 한번에 교체 가능
✦ Builder
✧ 작게 분리된 Instance를 건축하듯 조합한 객체 생성 Pattern
✧ 객체 생성 <-> 표현 방법 간 분리 > 동일한 객체 생성에도 결과 상이
✦ Factory Method, Virtual Constructor (=가상 생성자 Pattern)
✧ Sub Class에서 객체 생성되게 분리해 캡슐화한 Pattern
✧ 상위 Class에서는 Interface만 정의, 실제 생성은 Sub Class가 담당
✦ Prototype
✧ 원본 객체 복제로 객체 생성 Pattern
✧ 일반적인 방법
✧ 비용 클 시 주로 사용
✦ Singleton
✧ 객체 생성 시 어디서든 참조 가능하지만 여러 Process가 동시 공용 불가
✧ Class 내 Instance가 하나 뿐임을 보장
✧ 메모리 낭비 최소화
Structural Pattern (=구조 Pattern)
✦ Class 및 객체를 조합해 더 큰 구조를 만드는 Pattern
✧ 복잡한 시스템 개발에 도움
✦ Adapter (=어댑터)
✧ 비호환 Class의 Interface를 호환되게 변환하는 Pattern
✧ 해당 Class 사용 가능해짐
✦ Bridge
✧ 구현부에서 추상층을 분리해 독립 확장 가능하게 구성하는 Pattern
✧ 기능, 구현을 2개의 별도 Class로 구현
✦ Composite (=컴포지트)
✧ 복합 객체(여러 객체를 가진 객체)와 단일 객체 간 구분 없이 쓸 때 쓰는 Pattern
✧ 복합 객체 내 복합 객체 가능
✧ Ex) 조금 다르지만 어쨌든 Directory 느낌
✦ Decorator (=데코레이터)
✧ 객체 간 결합으로 능동적 기능 확장 시 쓰는 Pattern
✧ 임의 객체에 부가적 기능 추가를 위해 타 객체를 덧붙임
✦ Facade (=퍼싸드)
✧ 복잡한 Sub Class를 피해 상위에 Interface를 구성해 쉽게 Sub Class를 쓰기 위한 Pattern
✧ Sub Class들 간 통합 Interface를 제공하는 Wrapper 객체 필요
✦ Flyweight (=플라이웨이트)
✧ Interface 필요 시마다 생성하지 않고, 가능한한 공유해 매모릴 절약하기 위한 Pattern
✧ 다수 유사 객체 생성 및 조작 시 유용
✦ Proxy
✧ 접근x 객체에 연결 시 Interface 역할 수행 Pattern
✧ 주로 Network 연결, 메모리 대용량 객체로의 접근 등에 사용
Behavioral Pattern (=행위 Pattern)
✦ Class나 객체들이 서로 상호 작용하는 방법이나 책임 분배 방법 정의
✦ 하나의 객체로 수행 불가능 한 작업을 여러 객체로 분배하면서 결합도 최소화
✦ Chain of Responsibility (=책임 연쇄)
✧ 요청 처리 가능 객체가 둘 이상 존재
✧ 처리 못하면 다음 객체로 넘어가는 형태
✧ Chain(고리)으로 묶여있어 해결될 때 까지 Chaining
✦ Command
✧ 요청을 객체 형태로 캡슐화해 재사용 및 취소 할 수 있도록 요청에 필료한 정보 저장 및 Logging
✧ 추상 Class 및 구체 Class로 명령어 분리
✦ Interpreter
✧ 언어에 문법 표현 정의
✧ SQL, 통신 Protocol 등 개발 시 사용
✦ Iterator (=반복자)
✧ 자료 구조와 같은 접근 잦은 객체에 대해 동일 Interface 사용케 하는 Pattern
✧ 내부 표현 방법 없이 순차 접근 가능
✦ Mediator (=중간자)
✧ 수 많은 객체들 간 복잡한 상호 작용을 캡슐화해 객체로 정의
✧ 객체 간 의존성 줄여 결합도 감소
✦ Memento
✧ 특정 시점의 객체 내부 상태 객체화 및 이후 요청에 따라 시점 되돌리기 가능
✧ Ex) 억지부리면, 실행 취소, Snapshot 등
✦ Observer
✧ 객체 상태 변화 시 객체 상속을 받는 객체에게 상태 변화 정보 전달
✦ State
✧ 객체 상에따라 동일한 동작 다르게 처리
✧ 객체 상태 캡슐화해 참조 방식으로 처리
✦ Strategy (=전략)
✧ 동일 계열 알고리즘들 개별적 캡슐화해 상호 교환 가능하게 정의
✧ Client는 알고리즘 독립적 선택 가능
✧ 알고리즘 변경 시 Client에 미영향
✦ Template Method
✧ 상위 Class에서 골격, 하위 Class에서 세부 처리
✧ 유사한 Sub Class들 묶어 공통된 내용을 상유를 Class에서 정의해 Code양 줄고 유지 보수 용이
✦ Visitor (=방문자)
✧ 각 Class들 데이터 구조에서 처리 기능 분리해 별고 Class로 구현
✧ 분리된 처리 기능은 각 Class를 방문하여 수행