ME.Dev

This Post will discover more than one design pattern. They are all good patterns, but some are not used these days. And some are just plain hard to implement, like the Interpreter Pattern . Abstract Factory Pattern : The Abstract Factory Pattern describes a factory of factories, or, more properly thought of, an abstract specification for an actual object factory . Here's the problem: sometimes you might need more than one factory to create objects of a similar nature. An Abstract Factory  is usually implemented as an abstract class that real, concrete factories extend. That unifies what the concrete factories do, while allowing leeway to fit differing requirements. The Abstract Factory Pattern  should " provide an interface for creating families of related or dependent objects without specifying their concrete classes. " Prototype Pattern : The Prototype Pattern  says that when it takes a lot of resources, or a lot of code, to create an object, you should co...

This post will be about the second pattern in the alliance. In the last post we explored first pattern in this alliance, the Iterator Pattern , and today is the time of  Composite Pattern . The Composite Pattern : The Composite Pattern  is all about creating tree-like structures where the leaves in the structure can be treated in the same way as the branches(which are substructures that can contain multiple leaves, as well as other branches). The idea here is that, to make life easier, you should be able to treat the leaves and compositions of leaves in a tree structure the same. You use the Composite pattern  to " Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformally ". That is typical of Composite Pattern - when you ask a branch to perform some action, it iterates over all its contained leaves and branches. The insight behind The Composite Pattern is r...