Aim: Identify typical industry cases for design patterns.

Theory:

Factory Method:
A creational pattern used to manufacture objects.
Intent:

Defines an interface for creating objects, but let subclasses to decide which

class to instantiate.
Refers to the newly created object through a common interface.

Motivation:
Also known as Virtual Constructor, the Factory Method is related to the idea on
which libraries work: a library uses abstract classes for defining and maintaining
relations between objects. One type of responsibility is creating such objects. The
library knows when an object needs to be created, but not what kind of object it
should create, this being specific to the application using the library.
The Factory method works just the same way: it defines an interface for creating an
object, but leaves the choice of its type to the subclasses, creation being deferred at
run-time.
Applicability:
Used when:

Class cant anticipate the specific type of objects to create

Class wants subclasses to specify the objects created

Class delegates some responsibility to one of several helper subclasses -want

to localize

Knowledge of which particular helper is the actual delegate.

Implementation
Take into consideration a framework for desktop applications. Such applications are
meant to work with documents. A framework for desktop applications contains
definitions for operations such as opening, creating and saving a document. The basic
classes are abstract ones, named Application and Document, their clients having to
create subclasses from them in order to define their own applications. For generating
a drawing application, for example, they need to define the DrawingApplication and
DrawingDocument classes. The Application class has the task of managing the
documents, taking action at the request of the client (for example, when the user
selects the open or save command form the menu).
Because the Document class that needs to be instantiated is specific to the application,
the Application class does not know it in advance, so it doesn't know what to
instantiate, but it does know when to instantiate it. The framework needs to instantiate
a certain class, but it only knows abstract classes that can't be instantiated.
The Factory Method design pattern solves the problem by putting all the information
related to the class that needs to be instantiated into an object and using them outside
the framework, as you can see below

Fig: Factory method framework

In the Application class the CreateDocument method either has a default
implementation or it doesn't have any implementation at all, this operation being
redefined in the MyApplication subclass so that it creates a MyDocument object and
returns a reference to it.
public Document CreateDocument(String type){
if (type.isEqual("html"))
return new HtmlDocument();
if (type.isEqual("proprietary"))
return new MyDocument();
if (type.isEqual("pdf"))
return new PdfDocument ();
}

Assuming that the Application class has a member called docs that represents a list of
documents being handled by the application, then the NewDocument method should
look like this:

public void NewDocument(String type){

Document doc=CreateDocument(type);
Docs.add(doc);
Doc.Open();
}

Drawbacks and Benefits

Here are the benefits and drawbacks of factory method pattern:

The main reason for which the factory pattern is used is that it introduces a
separation between the application and a family of classes (it introduces weak
coupling instead of tight coupling hiding concrete classes from the
application). It provides a simple way of extending the family of products

with minor changes in application code.

It provides customization hooks. When the objects are created directly inside
the class it's hard to replace them by objects which extend their functionality.
If a factory is used instead to create a family of objects the customized objects

can easily replace the original objects, configuring the factory to create them.
The factory has to be used for a family of objects. If the classes doesn't extend
common base class or interface they cannot be used in a factory design
template.

The Observer Pattern

The Observer design pattern, or more accurately some implementation of this pattern,
is used to assure consistency between different objects. For example, let the state of
an object "B" depend on the state of an object "A". Whenever the state of object "A"
changes, "B" has to recompute its state in order to remain consistent with "A". The
observer design pattern supports such dependencies and at the same time tries to
reduce the coupling between the object that changes (the subject) and the object that
needs a change notification (the observer).
Implemenatation
The participants classes in this pattern are:

Observable - interface or abstract class defining the operations for attaching

and de-attaching observers to the client.

ConcreteObservable - concrete Observable class. It maintain the state of the

object and when a change in the state occurs it notifies the attached Observers.
Observer - interface or abstract class defining the operations to be used to

notify this object.

ConcreteObserverA,

ConcreteObserver2 -

concrete Observer implementations.

The flow is simple: the main framework instantiate the ConcreteObservable object.
Then it instantiate and attaches the concrete observers to it using the methods defined
in the Observable interface. Each time the state of the subject it's changing it notifies
all the attached Observers using the methods defined in the Observer interface. When
a new Observer is added to the application, all we need to do is to instantiate it in the
main framework and to add attach it to the Observable object. The classes already
created will remain unchanged.

Fig: Observer Pattern

Example - We focus on the simple case: One subject with one or more observers,
where the observers are completely isolated from each other. If the state of object "B"
depends on the state of object "A", it should be "B"'s responsibility to synchronize its
state whenever "A" changes. How does "B" know when "A" changes state? The first
possibility is that "A" notifies "B" of any change, as in the previous code snippet. The
second possibility would be that "B" checks periodically to see if "A" has changed. A
third possibility would be that "B" is notified by some other object "C" and "C" is
notified using one of the first two methods.

1) Notification
In this implementation option, "A" holds a pointer to object "B" and whenever "A"
changes state, it calls some notification method of "B". If we view this strategy as an
independent concept, we get the Observer design pattern. The concept can be
supported by some general-purpose OO library, allowing reuse. If the update of the
observer is not triggered by the subject automatically, we need an additional interface
for a "subject". The only method in this interface is the "update" method that tells the
subject to notify its observers.
By using the Subject/Observer interfaces, we can decouple classes representing
different abstractions. What if the other class uses the pattern but has defined its own
Subject/Observer interfaces? Then you have different interfaces for the same
abstraction. Then again you have to subclass and, if these interfaces don't diverge too
much, it will work.
2) Polling
In this implementation option, the observer "B" queries the subject "A" to see if there
was a state change. The advantage of this approach would be that "A" is completely
independent of "B". "A" neither needs an "Observer/Subject" interface nor a pointer
to "B" (or some set of observers). In this case, there is no need for the subject to be
"observer-ready". The subject doesn't have to maintain old states or call "notify" in
state changing methods. The responsibility for consistency shifts completely to the
observing object, increasing the subject's reusability and maintainability.
From this point of view, the polling implementation is more favorable. Two main
disadvantages of polling come to mind:
1. Who notifies the observer to poll its subject(s)? How do you assure that this
doesn't happen too early/too late. If the subject is polled too early, the observer

may update on an old or illegal state. If the subject is polled too late, transitions
may be lost.
2. Because the subject is polled even if it doesn't change, overhead is introduced.
Since both problems are significant, the polling option is undesirable for most
situations. But sometimes it's the better option.
GUI frameworks
Let's say your observer is some part of a graphical user interface (GUI). A GUI will
have something called either an "event loop" or a "main loop". This loop will receive
and dispatch events form various sources, for example the mouse, the keyboard, etc.
An object can receive control periodically by registering itself at the event loop (you
can use the Observer interface for this). After each processed event, the event loop
object calls "notify" on itself, which in turn calls "update" on each observer. Each
observer then queries its subject as part of its "update" implementation and
recomputes its state. Because update is called on each interested object after every
user initiated event, this method is very powerful for controlling GUI elements that
need to update after the user has manipulated some part of the interface.
Conclusion: Thus we successfully studied typical industry cases for design patterns
(Factory pattern and Observer pattern).