데코레이터(Decorator) 패턴
목표는 ocp,즉 변경하지않고 확장하는게 목표
이 패턴은 인터페이스를 하나 만들고,모든 구현체들이 이 인터페이스를 구현하게해서 서로서로 겹칠수있게 하는게 목적인 패턴임
즉,데코레이터 패턴은
객체에 추가요소를 동적으로 더할수있게 만드는 패턴,이걸 사용하면 서브클래스보다 훨씬 유연하게 기능을 확장할수있음
여기서 인터페이스는 메서드를 주는게 목적이 아닌,모든 객체들이 동일한 메서드를 가지고 사용할수있게하는게 목적임
이건 종이컵을 겹쳐놓는다는 이미지랑 비슷하다고 생각함(래퍼객체라고 생각해도됨)
모든 구현체들은 자기 인터페이스에 해당하는 변수를 di받고,그걸통해 재귀처럼 타고내려가면서 기능을 수행할수 있게 하는 패턴임,
즉 만들때의 핵심은
- 모든 구현체에 동일한 인터페이스를 구현시킴
- 자기 인터페이스와 동일한 지역변수를 모든 구현체에 생성
- 인터페이스에 있는 메서드를 호출할때,인터페이스변수의 메서드를 호출(보통 마지막인데 경우따라 다름)
이 3가지임
이러면 런타임에서 계속 객체들을 덮어가며 생성하다가 마지막에 해당 메서드를 한번 호출하면 모든 덮은객체들의 해당메서드가 호출되는식임
이 패턴의 장점은 행동이 컴파일시에 결정되지않고,동적으로 런타임시에 결정할수있다는거
또한 그래서 클래스폭발(클래스갯수가 무지막지하게 늘어나는것)이 일어나지않고,확장이 쉬움(인터페이스 구현만하면 덮어씌워지니까)
단점은 잡다한 클래스가 매우 많아져서 알아보기 힘들수있음
이때 주의점은,이 패턴은 모든것을 같은 인터페이스로 취급하는데 있기때문에,만약 특정 구현체를 특별취급(할인등)을 해야한다면 사용할수없음,즉 데코레이터의 가장 큰 장점인,클라는 데코레이터를 썼는지 아닌지 알수없음이 무효화돼버림
또한 데코레이터를 파고들어가서 해당 데코레이터가 무슨일을 하는지 알아야하거나 그렇다면 이 패턴을 사용하지않는게 좋음
데코레이터 패턴은 팩토리나 빌더패턴과 같이쓰면 좀 단점을 보완할수있음