Head First C++ code for PizzaStore : Abstract Factory Pattern

After Factory method, Chapter 4 in the Head First Design Patterns book explains Abstract Factory design pattern.

" The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. "

Both Factory Method and Abstract Factory create objects but the key differences are :

1. Factory Method create objects through inheritance, that is you need to extend a class and override a factory method. Whereas Abstract Factory create through object composition, it provide an abstract type for creating a family of products. Subclasses of this type create products. To use the Abstract Factory , you instantiate one and pass it into some code that is written against the abstract type.
2. Factory Method is to just create one Product and each subclass is to decides which concrete class of Product to instantiate. Whereas Abstract Factory provides an abstract interface for creating a family of Products.
3. Methods to create products in an Abstract Factory are often implemented with a Factory Method!

In the example code PizzaIngredientFactory is implemented as an Abstract Factory because we need to create family of Products ( the ingredients). PizzaIngredientFactory provides an abstract interface for creating a family of products. The subclasses as 'NYPizzaIngredientFactory' uses factory method like 'createDough()' in an Abstract Factory pattern.

Here is the class diagram of PizzaStoreV2

The c++ code is build using VS2010 IDE. You can download code from here.

Head First C++ code for PizzaStore : A Factory Method Pattern

Chapter 4 in the Head First Design Patterns book explains Factory Method design pattern. As we learned in previous posts to "encapsulate what varies", we can apply same technique to "encapsulate the code that create objects". When you have code that create objects or instantiates concrete classes, then it can be an area of frequent change.

We create objects by using new operator but there is more to making objects than just using new operator. As per design principle 2 we should "Program to an interface, not an implementation". Why ? Because if code is written to an interface, then it will work with any new classes implementing that interface through polymorphism. When I say interface here then in C++ there is no clear distinction between interface and abstract class, unlike in C# and Java. To get a fair idea of interfaces and abstract classes in C++, you can refer stackoverflow discussions here and here. Generally speaking interface can also refer to a function's signature.
Whenever you see "new", think "concrete". When you use "new" you are certainly instantiating a concrete class, so that's an implementation and not an interface. When you have a code that makes use of lots of concrete classes then it will be prone to bugs because code may have to be changed as new concrete classes are added. So code will not be "closed for modifications" and hence violate our design principle 4 discussed in last post.
Anywhere in a code if you use "new", you'll be holding a reference to a concrete class, you should be using a Factory method to get around that! Factory method can be defined as

" The Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses."

The 'interface' above is factory 'method'. A factory method handles object creation and encapsulates it in a subclass. This decouples the client code in the superclass from the object creation code in the subclass. A factory method looks like

        abstract Product factoryMethod(String type)

A factory method returns a Product that is typically used within methods defined in the superclass. Client is actually code in superclass, factoryMethod isolates the client code from knowing what kind of concrete Product is actually created.

In the example code the PizzaStore class is the Creator class that contains the implementations for all of the methods to manipulate products, except for the factory method. The abstract factoryMethod ( createPizza(string) ) is what all Creater subclasses must implement ( ChicagoPizzaStore, NYPizzaStore ). The Concrete Creater( ChicagoPizzaStore, NYPizzaStore ) implements the factoryMethod(), which is the method that actually produce Products.
Pizza is the Product and all concrete products ( NYStyleCheesePizza, ChicagoStyleCheesePizza ... ) must implement the same interface so that the classes which use the products can refer to the interface not the Concrete Product ( NYStyleCheesePizza, ChicagoStyleCheesePizza etc. ).

Here is the class diagram of PizzaStore

The c++ code is build using VS2010 IDE. You can download code from here.

Head First C++ code for StarbuzzCoffee : A Decorator Pattern

The third chapter in the Head First Design Patterns book explains another fundamental design principle that forms the basis of Decorator design pattern. The fourth design principle can be summed as

"Classes should be open for extension, but closed for modification."

The example code in Chapter 3 the Decorator Pattern provide Java Implementation of StarBuzzCoffee billing application. I tried to write similar code in C++ that explains the Decorator Pattern used in the program.
Inheriting from Base class that implements a lot of methods is not a good idea, as some of sub-classes might not need all the functionality (methods) of Base class. Also it violates design principle 2 explained in previous post.
Inheriting behavior by sub classing, set the behavior statically at compile time. And all sub-classes must inherit the same behavior. If object's behavior is extended through composition (has-a), then it can be extended dynamically at a runtime.
It is possible to add multiple new responsibilities to objects through this technique (composition), including responsibilities that were not even thought of by the designer of the superclass. And we don't have to touch their code! By dynamically composing objects, new functionality can be added by writing new code than altering existing code. This reduces chances of introducing Bugs.

Decorator pattern provides an alternative to sub-classing for extending behavior, it attaches additional responsibilities to an object dynamically. Decorators need the same "interface" as the component they wrap because they need to stand up in place of the component.
In the example code we subclass the abstract class Beverage in order to have correct type, not to inherit its behavior. The behavior is acquired by composing objects together. Decorators change the behavior of their components by adding new functionality that they achieve by wrapping the component of same type ( Since Decorator extends the same Base class as components they wrap).
Here CondimentDecorator class provides decorator interface that will wrap the objects of type Beverage ( Sub-classed from), that is why Condiment inherit from same abstract class Beverage, but it inherits from Beverage to get type so that it can wrap beverages. The behavior will be extended by composition dynamically as CondimentDecorator store reference to Beverage.

Here is the class diagram of StarBuzzCoffee

The c++ code is build using VS2010 IDE. You can download code from here.