Factory Method Pattern

All factory patterns encapsulate object creation.

The Factory Method pattern encapsulates object creation by letting sub-classes decide what objects to create.

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.

Creator is not tightly coupled to any ConcreteProduct.

Franchising the pizza store

Each franchise might want to offer different styles of pizzas (New York, Chicago, and California) depending on where the franchise store is located and the tastes of the local pizza connoisseurs.

Approach 1

Approach 2

What if franchises were using your factory to create pizzas, but starting to employ their own home grown procedures for the rest of the process: they'd bake things a little differently.

You would really want to create a framework that ties the store and the pizza creation together, yet still allows things to remain flexible. 

Framework for the Pizza store

Declaring a 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.

We have gone from having an object handling the instantiation of our concrete classes to a set of subclasses that are now taking on that responsibility.

Simple Factory

If you have code that makes use of lots of concrete classes, you're looking for trouble because that code may have to be changed as new concrete classes are added.

So, your code will not be closed for modification.

Remember: Designs should be open for extension but closed for modification. 

class PizzaStore 

Pizza class

What if you want to add/delete pizza types

Encapsulating Object Creation

into a Factory class

Reworking the PizzaStore class

SimplePizzaFactory simpleFactory = new SimplePizzaFactory();
PizzaStore pizzaStore = new PizzaStore(simpleFactory);
pizzaStore.order("Veggie");

Class diagram

Singleton Pattern

Singleton Pattern

Ensures a class has only one instance, and provides a global point of access to it.

Lazy initialization

Use lazy initialization when you want a Singleton instance to be created on demand. 

This way you are not creating an instance (say if the instance creation logic is time consuming) if it is not needed.

Lazy Initialization + multi-threaded scenarios

Approach 1

Use the following if getInstance() method isn't causing substantial overhead for the application.

So, if a high traffic part of the code begins using getInstance(), you may reconsider, and use approach 2.

Synchronizing a method can decrease performance by a factor of 100.

Approach 2 

Use "double-checked locking" to reduce the use of synchronization in getInstance()

Eager initialization

If the application always uses a Singleton instance, you can create the singleton instance eagerly.
This is also thread-safe.

Strategy Pattern

Each type of Duck should implement its own display, so display is an abstract method in parent Duck

What if not all the types of Duck fly, but only a few of them do.
By putting fly in the parent Duck, we are giving ability for all the types of Duck to fly, but only few types of Ducks can fly.

This is to say that the fly behavior is not constant across all types of Ducks. Each type of Duck

You'd have to override fly() and quick() for every new Duck subclass that's ever added to the program ... forever.

Design Principle

Identify the aspects of your application that vary and separate them from what stays the same.
Take what varies and encapsulate it so it won't affect the rest of your code, so that you can alter or extend the parts that vary without affecting those that don't.