[7주차-2] 디자인패턴 추가조사 - 데코레이터 패턴

커피메이커에 추가할만한 디자인 패턴에 대해서 알려달라고 제미나이에게 물어봤더니, '데코레이터 패턴'을 조금 더 조사해보라는 조언을 주었다.

 

1. 데코레이터 패턴

옷을 입는 것이 데코레이터 패턴의 사용 예시라고 한다.

옷을 입는 것은 데코레이터 패턴의 좋은 예다.

링크에서 설명하는 바에 따르면, 추울 때 두꺼운 옷을 입거나 비올 때 방수점퍼를 입음으로써 나의 기능?을 쉽게 '확장'할 수 있지만, 옷은 내 일부가 아니기에 더우면 벗어버리기도 쉽다는 장점이 있다. 

 

2. 데코레이터 패턴의 구조

 - Component (Interface) : 원본 객체와 장식된 객체 모두를 묶는 역할
 - ConcreteComponent : 원본 객체 (데코레이팅 할 객체)
 - Decorator : 추상화된 장식자 클래스 => 원본 객체를 합성(composition)한 wrappee 필드와 인터페이스의 구현 메소드를 소유
 - ConcreteDecorator : 구체적인 장식자 클래스
     => 부모 클래스가 감싸고 있는 하나의 Component를 호출하면서 호출 전/후로 부가적인 로직을 추가할 수 있다.

 

데코레이터 패턴을 사용함으로써 총 세 개의 이득을 볼 수 있다. OCP 규칙을 준수하므로, 한 클래스를 전혀 수정하지 않고 다양한 확장 기능을 추가할 수 있고, SRP 규칙을 준수하므로 책임이 명확히 분리되어 구분이 편하다는 장점도 존재한다. 무엇보다도 다양한 객체들을 원하는 대로 조립해서 수백가지의 조합을 만들 수 있는 유연성까지 확보할 수 있다고 한다!

 

3. 데코레이터 패턴을 사용할 때 주의사항

1) 복잡한 객체 생성
새로운 객체를 만들 때 옵션이 많아지면(new 괄호 안에 새로운 new 괄호 안에 새로운 new 괄호 안에......) 이 생성자 코드가 매우 복잡하고 길어진다는 단점이 있다! 즉, 데코레이터 패턴만 사용하는 것이 아니라 빌더(Builder) 패턴 또는 팩토리(Factory) 패턴과 함께 사용하는 것이 좋다고 한다.

2) 객체 정체성(Identity) 문제
데코레이터 패턴에 따라 포장된 객체는 더 이상 원본 객체의 구체적인 타입으로 인식되지 않고 오직 공통 인터페이스의 타입으로 인식된다. 애초에 instanceof를 써서 구체적인 타입을 확인하려는 설계 자체가 LSP의 위반일 수 있다고 한다. 즉, 항상 상위 인터페이스 타입으로만 객체를 다루도록 코드를 설계하는 것이 좋다고 한다!

 

4. 느낀 점 

이걸 커피메이커에 적용하면 조금 더 클린코드에 가까워질 수 있지 않을까? 아직 코딩을 잘 못해서 조금 막연한 감이 있더라도.. 언젠가는. 추가 조사를 통해 더 다양한 디자인 패턴이 존재한다는 것을 알았고 이것이 꽤 신기했다. 전부 다는 힘들더라도 한두개만 적용해서 코딩한다면 협업에 큰 도움이 될 것이란 생각이 들었다.

 

사진 / 설명 참고 출처 

> https://refactoring.guru/ko/design-patterns/decorator

데코레이터 패턴

 > https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EB%8D%B0%EC%BD%94%EB%A0%88%EC%9D%B4%ED%84%B0Decorator-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90#%EB%8D%B0%EC%BD%94%EB%A0%88%EC%9D%B4%ED%84%B0_%ED%8C%A8%ED%84%B4_%EA%B5%AC%EC%A1%B0