Composable Decorators vs Imperative Utility Methods

[AmitKumarDas]

• Non Procedural Code

  class Foo {
    public List<String> names() {
      return Foo.with(
        Foo.with(
          new LinkedList(),
          "Jeff"
        ),
        "Walter"
      );
    }

  private static List<String> with(
      List<String> list, String item) {
      list.add(item.toLowerCase());
      return list;
    }
  }

  - it is good to return s.t. caller can use it in its args

  list.add("Jeff");
  Foo.withEnoughSpace(list).add("Walter");

  - reference: https://dzone.com/articles/temporal-coupling-between-method-calls

• Composable Decorators vs Imperative Utility Methods

  - decorator in real world sense do the job of delegating
  - make code highly cohesive & lossely coupled
  - keep on composing the code & finish the feature with less effort
  - do not use imperative UTILITY methods that make the code procedural

  - interface I & compose I == Composable Decorators
  - e.g. new PrintableText (new TextInFile (new File("/tmp/a.txt")));
  - e.g. new AllCapsText (new TextInFile (new File("/tmp/b.txt")));

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

  - class String in Java.lang - a bad design example
  - so many utility methods like trim, toUpperCase, split, ...

  - txt.trim().toUpperCase().split(" ");
  - above is imperative & procedural programming

  - new String.UpperCase( new String.Timmed("hello word"));
  - above makes the code object oriented & declarative

  - summary - Avoid utility methods & try having decorators instead.

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