도서관 소식을 유저에게 알리는 프로그램이 있다.
초기 요구사항에는 전달방식이 이메일 하나만 있었다.
그리고 전달방식에 Facebook, Slack이 추가되었다.
subclass로 둬 추가 요건을 반영했다.
그러자 한 사용자가 여러 Notifier를 가질 수 있다는 요건이 추가되었다.
모든 조합을 subclass로 뒀다... 너무 복잡해지고 한 클래스에 많은 책임이 생겨 SRP를 위배한다! 어떻게 개선할 수 있을까?
추가요건을 상속
으로 해결하려고 하다보니 이런 문제가 발생했다. 상속은 다음과 같은 문제가 있다.
이를 Composition
또는 Aggregation
으로 해결하고자 한다!
- Composition: Wrapper(Person)과 Wrapped(Heart)가 같은 생명주기를 갖는다.
// 전체 생성 Person person = new Person(); // 전체 생성자 내 Person() { heart = new Heart(); }
- Aggregation: 각각 다른 생명주기를 갖는다.
Heart heart = new Heart(); Person person = new Person(heart);
이를 이용해 다음과 같이 구현하다고 생각해보자
이렇게 구현한다면,
위와 같이 동작하는 Decorator Pattern이란,
주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴이다.
한 번 구성하면 Wrapped를 없애기 쉽지 않다!
Java I/O에서 사용된다.
serialized Java objects in a Gzipped file가 있고 빠른 속도로 읽어와야하는 상황이라고 가정하자.
FileInputStream fis = new FileInputStream("/objects.gz");
BufferedInputStream bis = new BufferedInputStream(fis);
GzipInputStream gis = new GzipInputStream(bis);
ObjectInputStream ois = new ObjectInputStream(gis);
이렇게 책임을 하나씩 붙이고 다음과 같이 사용한다!
SomeObject someObject = (SomeObject) ois.readObject();
상황에 맞게 자유롭게 stream을 데코레이트하는 것을 확인할 수 있다!
https://refactoring.guru/design-patterns/decorator
https://www.google.com/url?sa=i&url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDecorator_pattern&psig=AOvVaw1UpIvHdtHYw7QbovWyFivp&ust=1617199397826000&source=images&cd=vfe&ved=0CAkQjhxqFwoTCNCbp7GX2O8CFQAAAAAdAAAAABAP
https://stackoverflow.com/questions/6366385/use-cases-and-examples-of-gof-decorator-pattern-for-io