Monthly Archives: March 2018

Facade design pattern

This one is as easy as it gets. You simply create a class which exposes a simple API and hides the complexity behind it. Facade pattern code example: public class Facade { public int simpleCall() { ComplicatedObject1 obj1 = process(); ComplicatedObject2 obj2 = processAgain(obj1); return obj2.getTheMeaningOfLife(); } }

Read more

Enforce noninstantiability with a private constructor

Sometimes we want to create a class that is non instantiable: a class of static helper methods or constants. Let’s see how to make sure that such a class is never instantiated. Why should’t we have separate helper method classes? In general, it is not considered a good object oriented design. But the world is not […]

Read more

Decorator pattern

A decorator extends base object by modifying its behaviour. Each decorator contains a base object type reference, and at the same time is of base object type. That way, decorators can be chained one over another, and none of them know, if the reference base object they contain is in fact a concrete base object […]

Read more

Consider a builder when faced with many constructor parameters

Constructors with many parameters are hard to read. The only clue you have about what each parameter means is its order. It is not easily readable. Even more troubles emerge, when we have optional parameters. Then we start to drown in a sea of constructors with different set of parameters, a so called telescopic constructor […]

Read more

Consider static factory methods instead of constructors

Event though a constructor is a fairly standard and natural way of creating instances of a class, there are other ways to do it. And they might be sometimes better suited to do the job that needs to be done. You ill find this pattern in many libraries API, just think of Integer.valueOf() or getInstance(). All […]

Read more