Design Pattern

Design Pattern의 효과
Design Pattern을 통해 내가 만들 소프트웨어에 어떤 class가 존재해야 하고 그들의 관계는 어떠해야 하는지를 빠르게 이해하고 접근할 수 있다.
최근 언어들은 Hello World!! 부터가 아닌
최소한의 구조가 갖춰진 프로젝트 형태에서 시작함
 
Design Pattern을 재사용하는 이유
재사용: 생산성(보다 빠른 시간안에 소프트웨어를 출시하기 위함)과 신뢰성(그 패턴이 오랫동안 사용되어 와서 대부분의 문제가 정리되었다고 봄) 증가, 개발 시간 감소
디자인 패턴도 재활용, 재사용한다.
 
Design Pattern
흔히 발생하는 문제에 대한 솔루션을 재사용한다. 특정 프로그래밍 언어의 특징을 반영하지 않는다. 코드와 밀결합된 것이 아니다. Class와 그들의 상관관계에 대한 것이다. 알고리즘의 상위개념이다.
객체지향 디자인 패턴: 전형적으로 클래스나 오브젝트 간의 상관관계를 보여준다.

 
Adapter Pattern
신입 사원이 주로 쓴다.
목표: 기존의 클래스, 코드를 수정하지 않으면서 서로를 연결하기 위해 만들어졌다. (건들면 안 되는 입력 파라미터 3개를 요구하는 adaptee와 입력 파라미터 1개를 요구하는 adaptee를 연결해주기 위해 중간에 adapter를 끼워 맞추는 것이다.) 양립 불가능한 인터페이스를 가진 클래스들을 작동하게 하기위한 코드이다.
Adapter 클래스가 adaptee를 호출한다.
c++에서는 adapter class가 어댑티 클래스를 상속했다.
C++은 다중 상속이 됨( istream, ostream을 상속받는 iostream)
다중 상속이 안되면, mixing class를 사용함.
Adaptee: 수정X
Adapter: 우리가 작성, 수정하는 코드
1대1의 관계
Adapter class가 adaptee를 부르고 클라이언트의 입력을 연결해주는 역할
adaptee, 클라이언트를 안 고쳐도 됨!
 
Façade Pattern
1대n의 관계
겉면만 모양을 유지하고 뒤는 좋게 바꾸는 것이다.
목적: 사용자의 interface는 바꾸지 않겠다.
Client가 Façade class를 호출하면 파사드는 필요에 따라 다른 클래스를 호출한다. 파사드 클래스의 메소드 안에서 클래스의 객체를 생성한다.
성능이 좋지 못하다는 단점이 있다.
사용자가 복잡한 서브 시스템에 직접 접근하지 못하도록 한다. 예쁜 인터페이스로 입구를 차단해버림
내부에 작동하는걸 외부에 보여줄 필요가 없다.
모든 프로그래밍 언어의 기본 철학
Information hiding, Encapsule 좋음
 
Decorator Pattern
객체가 동적으로 움직이고 있는 중에 특정 기능을 추가하고 뺄 수 있다. 게임에서는 아이템이나 무기를 추가할 수 있도록 하는 디자인 패턴이다. 즉 기능을 추가할 수 있다.
1대n의 관계

Component를 base로 하여 concreteComponent와 decorator class를 생성하고 decorator를 base로 하는 concreteDecorator class를 생성한다. Decorator는 component 클래스와 has relationship 관계이다. 이때 ConcreteComponent는 가장 기본적인 아무것도 없는 캐릭터이고, concreteDecorator는 갑옷, 칼, 총 등 추가되는 아이템들이다.
ConcreteComponent: 가장 기본적인 아무것도 없는 캐릭, 먼저 실행됨
ConcreteDecorator: 갑옷, 칼, 총 등 추가되는 아이템들
 
Singleton
반드시 하나의 객체만 존재해야 한다. 절대로 이 클래스에서 만들어진 객체가 두 개 이상이면 안 된다. Ex) 자원을 관리하거나 중요한 데이터를 관리하는 프로그램에서 사용됨, 하드웨어의 자원은 물리적으로 하나이다. 두개 이상의 제어가 발생할 경우 충돌한다.
 
최근에 나온 소프트웨어 디자인 관련 책: clean code, clean, architecture
디자인 패턴은
SW 설계에 있어 시행착오를 줄여 줌
Design Pattern은 매우매우매우 호불호가 갈릴 수 있음
클래스 다이어그램으로 시각화
언어마다 구조가 다를 수 있음 -> Dependency
 
디자인 패턴의 비판
1. poor language
언어가 별로 안 좋아서 기능적을 부족한 게 많아서 디자인 패턴을 고민하는 것 아니냐?
23개 중 16개 의미가 없었음
-> 그래도 7개는 의미 있네, 쓰기 싫으면 쓰지마 (호불호 갈림)
2. 불필요하게 복잡성만 높인다.