# 디자인 패턴

### 브릿지 패턴

기능과 구현에 대해 두개를 별도의 클래스로 구현하는 방법(기능 : protocal, 구현: class or struct)

즉 프로토콜에 기능만 정의해두고 구현부분을 다르게 한다.

### Decorator 패턴

잘 안쓴다... 아마 pop로 다중 채택이 되기때문에 굳이 이러한 방법을 쓰진않는다.

### Facade 패턴

어떠한 기능을 사용할때 여러 인스턴스를 사용하거나 복잡하게 구현을 해야될시
Facade 패턴 내부에서 다 처리를 하여 외부에서 간단하게 facade.메서드로 실행을 하게 해주는 방법

### Proxy 패턴

할수 있는만큼 해주고 나머지 일을 넘겨주는 패턴
즉
클라이언트 -> 프록시 -> 실제 처리 객체
여기서 프록시는 실제 처리 객체에 일부분을 처리하여 넘겨줄수도 있고 뭐 하여튼 여러가지이다.

🌳 Proxy Pattern의 장단점
장점
realSubject가 메모리가 큰 인스턴스 일 경우 해당 인스턴스를 생성하는 시점을 정말로 필요한 시점에 지연시킬 수 있습니다.
Proxy는 realSubject가 준비되지 않았거나, 사용할 수 없는 경우에도 동작 합니다.
개방 폐쇄 원칙을 지켜 RealSubject나, 클라이언트를 변경하지 않고, 새로운 프록시를 도입할 수 있습니다.
단점
Proxy 클래스를 도입해야 함으로 코드가 복잡해 집니다.
RealSubject의 응답이 지연될 수 있습니다.

### Composite 패턴