Understanding how to create an object goes beyond the new() syntax, a good designer will think about the current requirement and future requirements to ensure decoupling layers, build in flexibility and maintainability. For example,
So you have an object that needs to create another class, however
…it cannot anticipate the class of objects it must create
…it wants only its subclass to specify the object it wants to create
…it wants to localize knowledge of which helper subclass is the delegate
How would you design for these quality attributes?
How about the following:
A client class needs a complex object, however it also
… wants to vary the product’s internal representation
…isolate code for construction and representation
…gives you greater control over the construction process
How would you design for these quality attributes?
What if you wanted to:
… isolate the concrete class from the client that needs it, and
… allow for exchanging classes of products easily
…enforce a common consistent product interface across families of products
What’s going to be the pattern of choice, designer?
If you answered Factory, Builder and Abstract Factory – then that’s pretty darn good – you remember your GOFs, which are like the ABCs for software architects (or should be).
+ 
= No Linux or Android
