It’s easy to discard the previous issue: it’s pretty straightforward to look at the code and check the implementation.

And yet, this check doesn’t imply that the dependency won’t change. Worse, the above example only brushes at the top of the iceberg. Another case involves core principles of OOP :

Both guidelines naturally lead to the Decorator pattern:

As an example, let’s use the Scalar hierarchy from the Cactoos library:

This design follows the above principles. It makes it very simple to compose different Scalar objects e.g.:

Scalar scalar = new StickyScalar < String >( new RetryScalar < String >( new Scalar < String >() { @Override public String getValue () { // Get the value from a network call } } , 3 ) );

All those nested decorator layers make it quite difficult to understand properties about the value. For example, in the above snippet, the StickyScalar keeps the value once it’s read successfully once. Underneath, there are 3 attempts to read from the network.