Composable Decorators vs. Imperative Utility Methods

https://www.yegor256.com/2015/02/26/composable-decorators.html

Composable Decorators vs. Imperative Utility Methods

 

composable decorators라는 이름이 흥미롭다. decorators들을 composable로 사용 할 수 있게 하는 패턴이다. imperative utility methods는 절차지향적 프로그래밍이라고 보면 된다.

 

해당 링크의 아래 예제에서 PrintableText는 Text가 어디서 왔는지 신경 쓰지 않아도 된다는 점, 신경 쓰지 않는다는 것은 곳 encapsulated가 잘되어 있다는 점에서 좋은 패턴이라고 한다

final Text text = new PrintableText(
  new TextInFile(new File("/tmp/a.txt"))
);
String content = text.read();

 

그리고 아래와 같은 형태로 decorators들을 composable 할 수 있는 방법을 설명해주고 있다.

final Text text = new AllCapsText(
  new TrimmedText(
    new PrintableText(
      new TextInFile(new File("/tmp/a.txt"))
    )
  )
);
String content = text.read();

그리고 객체가 생성되어도 read()가 호출되기 전까지 아무런 오퍼레이션을 하지 않는다는 점에서 절차지향적 프로그래밍과는 다르다고 설명한다.

 

마지막으로 자바의 절차지향적인 String method()와 객체지향적 선언적 프로그래밍의 방법을 비교해준다.

final String txt = "hello, world!";
final String[] parts = txt.trim().toUpperCase().split(" ");

vs

final String[] parts = new String.Split(
  new String.UpperCased(
    new String.Trimmed("hello, world!")
  )
);

디자인 상으로는 아래가 좋다고 생각한다. 단일책임의 원칙에 따라 한 클래스는 하나의 책임을 맡을 수 있어 객체가 스스로를 가공하는 로직을 가지지 않아도 된다. 그럼에 따라 각각의 클래스가 하는 동작을 encapsulate할수 있다고 생각한다. 하지만 String 클래스의 메소드 사용도 괜찮지 않을까 생각한다. 이미 널리알려진 JDK라는 관점에서 encapsulate되었다고 볼 수 있다고 생각한다. 절차지향은 사람의 생각의 흐름대로 따라갈 수 있기 때문에 이해하고 사용하기 쉽다고 하지만 쉽다고 해서 꼭 좋은 디자인으로만은 볼 수 없다.