Iterator Pattern

The Iterator Pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Once you have a uniform way of accessing the elements of your aggregate (collection) objects, you can write polymorphic code that works with any of these aggregates.

The other important impact on your design is that the Iterator Pattern takes the responsibility of traversing elements and gives that responsibility to Iterator object, and not the aggregate object. This keeps the aggregate interface and implementation simpler. It removes the responsibility for iteration from the aggregate and keeps the aggregate focused on the things it should be focused on.

The core principle behind this pattern is Single Responsibility Principle, which states that "A class should have only one reason to change".

Every responsibility of a class is an area of potential change. More than one responsibility means more than one area of change. So this principle guides us to keep each class to a single responsibility.

Java language provides the iterator interface (java.util.iterator) and all collection objects in Java already implement this interface.

State Pattern

The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

This design pattern should be considered when the application needs to maintain certain state machine.

The State Pattern suggests that:

1. Encapsulate each state into a separate class.
2. The Context delegates to the current state to handle requests.
3. Once a request is handled, the current state may change.

Design Principles follows:

1. Encapsulate what varies.
2. Favor composition over inheritance.
3. Open-Closed principle: closed for modification but open for extension.

State and Strategy patterns are similar in structure, but what they intent to do is quite different.

In case of Strategy Pattern, objects stick to one particular kind of a behavior.

In case of State Pattern, objects change state over time according to some well defined state transitions.

Vending machine implementation is a very good application of a State Pattern.

Decorator Pattern

The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorator provides a flexible alternative to sub-classing for extending functionality.

There are two important parts to the Decorator Pattern:

1. Components
2. Decorators

There will be one abstract class for the components and all Concrete Components will extend this abstract component class. Also there will be one abstract Decorator class which extents the abstract component class. All concrete decorators will extent abstract Decorator class.

Design Principle: "Class should be open for extension but closed for modification".

This principle is called open-closed principle. This is one of the most important design principles.

Java IO libraries are implemented using Decorator Pattern.

Observer Pattern

The Observer Pattern defines one-to-many relationship between objects so that when object changes state, all of its dependents are notified and updated automatically.

Observer Pattern fits in a scenario, where there is one Subject (object) and many Observers (dependent object). The main idea behind this design pattern is loose coupling.

Design Principle:
"Strive for loosely coupled designs between objects that interact.".

When two objects are loosely coupled, they can interact, but have very little knowledge about each other. The Observer Pattern provides an object design where subjects and observers are loosely coupled.

Because:

• The only thing the subject knows about an observer is that it implements certain interface.
• New observers can be added anytime.
• No need to modify subject to add new types of observers.
• Subjects and Observers can be reused independently of each other.
• Changes to either the subject or an observer will not affect other.

Applications of Observer Pattern:

1. Weather Application

2. Stock Quotes

3. Newspaper subscription

Strategy Pattern

Strategy Pattern suggest following design strategy:

1. Define a family of algorithms (an interface)
2. Encapsulate each one and make them interchangeable (composition)
3. The idea is to let the algorithm vary independently from clients that use it.

Principles behind Strategy Pattern:

1. Identify the aspects of your application that vary and separate them from what stays the same.
    - take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don't.

2. Program to an interface, not an implementation.
    - "program to an interface" really means "program to a supertype".

3. Favor composition over inheritance.
    - this allows you to change behavior at runtime as long as the object you are composing with implements the correct behavior interface.

What problems are solved by Strategy Pattern?

1. Changing Code in sub-classes
2. Duplicate Code