The Adapter Patterm

The Adapter Pattern

Defined

The Adapter Pattern converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

Diagrams

Despite having defined the pattern, there are actually two kinds of adapters: Object adapters and Class adapters.

 Object Adapter:

Class Adapter:
- Can only be use in multiple inheritance languages
- The only difference is that with class adapter we subclass the Target and the Adaptee, while with object adapter we use composition to pass request to an Adaptee.

Code Example

 

Bullet Points

•  When you need to use an existing class and its interface is not the one you need, use an adapter.
• An adapter changes an interface into one the client expects.
• Implementing an adapter may require little work or a great deal of work depending on the size of the target interface.
• There are two forms of the Adapter Patter: Object and class. Class adapters require multiple inheritance.
• An adapter wraps an object to change its interface.  a decorator wraps an object to add new behaviors and responsibilities and a facade wraps a set of objects to simplify.
  

 

The Command Pattern

The Command Pattern

Defined

 The Command Pattern encapsulates a request as an object, thereby letting you parametrize other objects with different requests, ques or log request and support undo-able operations.

- A command object encapsulates a request, by binding together a set of actions on a specific receiver. To achieve this, it packages the actions and the receiver up into an object that exposes just one method, execute(). When called, execute() causes the actions to be invoked on the receiver,From the outside, no other objects really know what actions get performed on what receiver, they just know that if they call the execute method their request will be serviced.

Diagrams

Code Examples

Macro Commands
- A Kind of command that can execute other commands... and more then one of them.

Bullet Points

• The Command Pattern decouples an object, making a request from the one that knows how to perform it.
• A Command object is at the center of this decoupling and encapsulates a receiver with an action (or set of actions).
• An invoker makes a request of a Command object by calling its execute() method, which invokes those actions on the receiver.
•  Invokers can be parametrized with Commands, even dynamically at run-time.
• Commands may support undo by implementing an undo method that restores the object to its previous state before the execute() method was last called.
• Macro Commands are a simple extension of Command that allow multiple commands to be invoked. likewise Macro Commands can easily support undo().
• In practice, it is not uncommon for "smart" Command Objects to implement the request themselves rather than delegating to a receiver.
• Commands may also be used to implement logging and transaction systems.

The Singleton Pattern

The Singleton Pattern

 

Defined

The Singleton Pattern ensures a class has only one instance, and provides a global point to access it.

Types of objects that we would only need one of : Drivers, registry settings. objects that handle preferences.

Ie.  A Kinect Device Manager object should be a singleton, because a Kinect application should be restricted to only having one open connection to a Kinect Device.

Diagrams

 

Code Example

CODE DISSECTION

 

                   Code Solution- to prevent two instances being created on different threads.

Bullet Points

• The Singleton Pattern ensures you have at most one instance of a class in your application
• The Singleton Pattern also provides a global access point to that instance. 
• Java's implementation of the Singleton Pattern makes use of a private constructor, a static method combined with a static variable.
• Examine your performance and resource constraints and carefully choose an appropriate Singleton implementation for multi-threaded applications (and we should consider all applications multi-threaded)

The Abstract Factory Pattern

The Abstract Factory Pattern

Defined

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

Diagrams

Use whenever you have families of products you need to create and you want to make sure your clients create products that belong together.

Bullet Points

• All factories encapsulate object creation.
• Simple Factory, while not a bonafide design pattern, is a simple way to decouple your clients from concrete classes.
• Factory Method relies on inheritance: object creation is delegated to subclasses which implement the the factory method to create objects.
• Abstract factory relies on object composition. object creation is implemented in methods exposed in the factory interface.
• All Factory Patterns promote, loose coupling by reducing the dependency of your application on  concrete classes.
• The intent of Factory Method is to allow a class to defer instantiation to subclasses.
• The intent of Abstract Factory is to create families of related objects without having to depend on concrete classes.
• Fa

The Dependency Inversion Principle

The Dependency Inversion Principle

it should be pretty clean that reducing dependencies to concrete classes in our code is a good thing. In Face, we've got an OO design principle that formalizes this nothing; it even has a big formal name for it.. 'the Dependency Inversion Principle'.

At first, this principle sounds a lot like " program to an interface, not a implementation" right?. it is similar; however, the Dependency Inversion Principle makes an even strong statement about abstraction. It suggests that our high level components should not depend on our low level components; rather they should bother depend on abstractions.

But what the heck does that mean?

Well, let's start by looking again at the first pizza store diagram. Pizza store is our "high-level component" and the pizza implementations are our "low-level components",  and clearly the Pizza Store is dependent on the concrete pizza classes.

Now this principle tells us we should instead write our code so that we are depending on abstractions, not concrete classes. That goes for both our high level models and our low-level modules.

But how do we do this? lets think about how we'd apply this principle to our very dependent Pizza-store implementation.



Applying the principle

Now the main problem with the Very Dependent PizzaStore is that it depends on every type of pizza because it actually instantiates concrete types in its orderPizza() method.


When you directly instantiate an object, you are depending on its concrete class.
While  we've created an abstraction, Pizza we're never-less creating concrete pizzas in the code, so we don't get a lot of leverage out of this abstraction.

How can we get those instantiations out of the orderPizza method? well, as we know, the Factory Method allows us to do just that.

So after we've applied the Factory Method, our 2nd diagram looks like this:


After applying the Factory Method, you'll notice that our high-level component, the PizzaStore, and our low-level components, the pizzas, both depend on Pizza, the abstraction. Factory Method is not the only technique for adhering to the Dependency Inversion Principle, but it is one of the more powerful ones.


Where is the "inversion" in Dependency Inversion Principle?
The "inversion" in the name Dependency Inversion Principle is there because it inverts the way you typically might think about your OO design. Look at the diagram on the previous page, notice that the low-level components now depend on a higher level abstraction. Likewise, the high level component is also tied to the same abstraction. So, the top-to-bottom dependency chart we drew first,  has inverted itself, with both high level and low-levels now depending on the abstraction.




A few guidelines to help you avoid violating the principle.

• No variable should hold a reference to a concrete class.
• No class should derive from a concrete class.
• No method should override an implemented method of any of its base classes.

The Factory Method Pattern

The Factory Method Pattern

 Defined

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.

As with every factory, the Factory Method Pattern gives us a way to encapsulate the instantiations of concrete types. Looking at the class diagram below, you can see that the abstract Creator gives you an interface with a method for creating objects, also known as the "Factory Method". Any other methods implemented in the abstract Creator are written to operate on products produced by the the factory method. Only subscribers actually implement factory method and create products.

As in the official definition, you'll often hear developers say that Factory Method lets subclasses decide which class to instantiate. They say "decides" not because the pattern allows subclasses themselves to decide at run-time, but because the creator class in written without knowledge of the actual products that will be create, which is decided purely by the choice of the subclass that us used.

- There is more to making objects than just using the new Operator.
- Seen a similar design where a factory is defined in a static method (Static factory).  whats the difference.  advantage of static method is you don't need to instantiate an object to make use of the create method. disadvantage that you cant subclass and change the behavior of the create method.

Factories handle the details of object creation.


Use me to decouple your client code from the concrete classes you need to instantiate, or if you don't know ahead of time, all the concrete classes you are going to need. To use me just subclass me and implement factory method.

Diagrams

Bullet Points

• All factories encapsulate object creation.
• Simple Factory, while not a bonafide design pattern, is a simple way to decouple your clients from concrete classes.
• Factory Method relies on inheritance: object creation is delegated to subclasses which implement the the factory method to create objects.
• Abstract factory relies on object composition. object creation is implemented in methods exposed in the factory interface.
• All Factory Patterns promote, loose coupling by reducing the dependency of your application on  concrete classes.
• The intent of Factory Method is to allow a class to defer instantiation to subclasses.
• The intent of Abstract Factory is to create families of related objects without having to depend on concrete classes.
• Factories are a powerful technique for coding to abstractions, not concrete classes.

Decorator/Wrapper Pattern

Decorator/Wrapper Pattern

DEFINED

The decorator pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for extending functionality.

Problems to be solved.- the over use of inheritance, equals class explosion
- When you inherit behavior by sub classing, that behavior is set statically at compile time. in addition all subclasses must inherit the same behavior.

Extension - extends an object behavior dynamically at run time by using composition,


When learned - allow you to be able to give your (or someone else) objects new responsibilities with making code changes to the underlying classes.

Decorates your classes at run time using a form of object composition.
- extension at run-time rather then at compile time.
-While inheritance is powerful it doesn't lead to the most powerful designs.
 -

Open-Closed principle
-Goal is to allow classes to be easily extended to incorporate new behavior without modifying existing code. 

- There are ways of "inheriting" behavior at run-time through composition and
-IT is possible to add multiple new responsibility to objects, through this technique, including responsibilities that were not even thought of by the designer of the super class. and you don't have to touch their code.
-Code should be closed for modification, yet open for extension
-  Takes time and effort to make code this flexible

- must be careful when choosing the areas of code that need to be extend; applying the open-closed principle EVERYWHERE is wasteful and unnecessary and can lead to complex hard to understand code.

Diagrams

 

 Code Example

 

Bullet Points

•   Inheritance is one for of extension, but not necessarily the the way way yo achieve flexibility in out designs.
• In our designs we should allow behavior to be extended without the need to modify existing code.
• Composition and delegation can often be used to add new behaviors at run time.
• The Decorator pattern provides an alternative to sub-classing for extending behavior.
• The Decorator patten involves a set of decorator classes that are used to wrap in concrete components.
• Decorator classes mirror the type of the components they decorate. (in fact they're same type)
• Decorators change the behavior of their components by adding new functionality before and/or  after (or even place of ) method calls to the component.
• You can wrap a component with any number of decorators.
• Decorators are typically transparent to the client of the component; that is, unless the client is relying on the component’s concrete type.
• Decorators can result in many small objects in our design, and overuse can be complex