OOSE Presentation Report

Group members

Usama Munir Mirza

70040395
Muaaz Khan
70068589
Suleman Ahmad
70068705
Hafiz Abuzar Waheed
70069669
 Observer Design Pattern
According to GoF definition, observer pattern defines a one-to-many dependency between
objects so that when one object changes state, all its dependents are notified and updated
automatically. It is also referred to as the publish-subscribe pattern.

In observer pattern, there are many observers (subscriber objects) that are observing a particular
subject (publisher object). Observers register themselves to a subject to get a notification when
there is a change made inside that subject.

A observer object can register or unregister from subject at any point of time. It helps is making
the objects objects loosely coupled.

When to use observer design pattern

As described above, when you have a design a system where multiple entities are interested in
any possible update to some particular second entity object, we can use the observer pattern.

The flow is very simple to understand. Application creates the concrete subject object. All
concrete observers register themselves to be notified for any further update in the state of subject.

As soon as the state of subject changes, subject notifies all the registered observers and the
observers can access the updated state and act accordingly.
Real world example of observer pattern

 A real world example of observer pattern can be any social media platform such as
Facebook or twitter. When a person updates his status – all his followers gets the
notification.

A follower can follow or unfollow another person at any point of time. Once unfollowed,
person will not get the notifications from subject in future.

 In programming, observer pattern is the basis of message oriented applications. When a

application has updated it’s state, it notifies the subscribers about updates. Frameworks
like HornetQ, JMS work on this pattern.
 Similarly, Java UI based programming, all keyboard and mouse events are handled by it’s
listeners objects and designated functions. When user click the mouse, function subscribed
to the mouse click event is invoked with all the context data passed to it as method
argument.
Architecture

Design participants
The observer pattern has four participants.

 Subject – interface or abstract class defining the operations for attaching and de-attaching
observers to the subject.
 ConcreteSubject – concrete Subject 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.
 ConcreteObserver – concrete Observer implementations.
 Proxy Design Pattern
According to GoF definition of proxy design pattern, a proxy object provide a surrogate or
placeholder for another object to control access to it. A proxy is basically a substitute for an
intended object which we create due to many reasons e.g. security reasons or cost
associated with creating fully initialized original object.

When to use proxy design pattern

A proxy object hides the original object and control access to it. We can use proxy when we may
want to use a class that can perform as an interface to something else.

Proxy is heavily used to implement lazy loading related usecases where we do not want to create
full object until it is actually needed.

A proxy can be used to add an additional security layer around the original object as well.

Real world example of proxy pattern

 In hibernate, we write the code to fetch entities from the database. Hibernate returns an
object which a proxy (by dynamically constructed by Hibernate by extending the domain
class) to the underlying entity class. The client code is able to read the data whatever it
needs to read with the proxy.

These proxy entity classes help in implementing lazy loading scenarios where associated
entities are fetched only when they are requested explicitly. It helps in improving
performance of DAO operations.

 In corporate networks, internet access is guarded behind a network proxy. All network
requests goes through proxy which first check the requests for allowed websites and
posted data to network. If request looks suspicious, proxy block the request – else request
pass through.
 In aspect oriented programming (AOP), an object created by the AOP framework in order
to implement the aspect contracts (advise method executions and so on). For example, in
the Spring AOP, an AOP proxy will be a JDK dynamic proxy or a CGLIB proxy.
Architecture

Design participants
 Subject – is an interface which expose the functionality available to be used by the clients.
 Real Subject – is a class implementing Subject and it is concrete implementation which
needs to be hidden behind a proxy.
 Proxy – hides the real object by extending it and clients communicate to real object via
this proxy object. Usually frameworks create this proxy object when client request for real
object.

what are different types of proxies

Proxies are generally divided into four types –

1. Remote proxy – represent a remotely lactated object. To talk with remote objects, the
client need to do additional work on communication over network. A proxy object does
this communication on behalf of original object and client focuses on real talk to do.
2. Virtual proxy – delay the creation and initialization of expensive objects until needed,
where the objects are created on demand. Hibernate created proxy entities are example of
virtual proxies.
3. Protection proxy – help to implement security over original object. They may check for
access rights before method invocations and allow or deny access based on the conclusion.
4. Smart Proxy – performs additional housekeeping work when an object is accessed by a
client. An example can be to check if the real object is locked before it is accessed to
ensure that no other object can change it.
 Command Design Pattern
Command pattern is a behavioral design pattern which is useful to abstract business logic into
discrete actions which we call commands. This command object helps in loose coupling
between two classes where one class (invoker) shall call a method on other class (receiver) to
perform a business operation.
In object-oriented programming, the command pattern is a behavioral design pattern in which an
object is used to encapsulate all information needed to perform an action, a business operation or
trigger an event e.g. method name, receiver object reference and method parameter values, if
any. This object is called command.

The similar approach is adapted into chain of responsibility pattern as well. Only difference is
that in command there is one request handler, and in chain of responsibility there can be many
handlers for single request object.

When to Use Command Pattern

You can use command pattern for solving many design problems e.g.

 Handling actions for Java menu items and buttons.

 Providing support for macros (recording and playback of macros).
 Providing “undo” support.
 Progress bars implementations.
 Creating multi-step wizards.

Popular Command Pattern Implementations

These are some real world examples of command pattern implementations:

 Runnable interface (java.lang.Runnable)

 Swing Action (javax.swing.Action) uses command pattern
 Invocation of Struts Action class by Action Servlet uses command pattern internally.
Architecture

Design Participants

Participants for command design pattern are:

 Command interface – for declaring an operation.

 Concrete command classes – which extends the Command interface, and has execute
method for invoking business operation methods on receiver. It internally has reference of
the receiver of command.
 Invoker – which is given the command object to carry out the operation.
 Receiver – which execute the operation.

In command pattern, the invoker is decoupled from the action performed by the receiver. The
invoker has no knowledge of the receiver. The invoker invokes a command, and the command
executes the appropriate action of the receiver. Thus, the invoker can invoke commands without
knowing the details of the action to be performed. In addition, this decoupling means that
changes to the receiver’s action don’t directly affect the invocation of the action.
 Builder Design Pattern
The builder pattern, as name implies, is an alternative way to construct complex objects.
This should be used only when you want to build different immutable objects using same object
building process.
Builder pattern aims to “Separate the construction of a complex object from its representation so
that the same construction process can create different representations.” It is used to construct a
complex object step by step and the final step will return the object. The process of constructing
an object should be generic so that it can be used to create different representations of the same
object.

 Product – The product class defines the type of the complex object that is to be generated
by the builder pattern.
 Builder – This abstract base class defines all of the steps that must be taken in order to
correctly create a product. Each step is generally abstract as the actual functionality of the
builder is carried out in the concrete subclasses. The GetProduct method is used to return
the final product. The builder class is often replaced with a simple interface.
 ConcreteBuilder – There may be any number of concrete builder classes inheriting from
Builder. These classes contain the functionality to create a particular complex product.
 Director – The director class controls the algorithm that generates the final product object.
A director object is instantiated and its Construct method is called. The method includes a
parameter to capture the specific concrete builder object that is to be used to generate the
product. The director then calls methods of the concrete builder in the correct order to
generate the product object. On completion of the process, the GetProduct method of the
builder object can be used to return the product.
 Existing implementations in JDK

All implementations of java.lang.Appendable are infact good example of use of Builder pattern
in java. e.g.

java.lang.StringBuilder#append() [Unsynchronized class]

java.lang.StringBuffer#append() [Synchronized class]

java.nio.ByteBuffer#put() (also on CharBuffer, ShortBuffer, IntBuffer, LongBuffer, FloatBuffer

and DoubleBuffer)

Another use can be found in javax.swing.GroupLayout.Group#addComponent().

Benefits and Advantages of Builder Pattern

Undoubtedly, the number of lines of code increase at least to double in builder pattern, but the
effort pays off in terms of design flexibility and much more readable code. The parameters to
the constructor are reduced and are provided in highly readable method calls.

Builder pattern also helps minimizing the number of parameters in constructor and thus there
is no need to pass in null for optional parameters to the constructor. It’s really attracts me.

Another advantage is that Object is always instantiated in a complete state rather than sitting in
an incomplete state until the developer calls (if ever calls) the appropriate “setter” method to set
additional fields.

And I finally I can build immutable objects without much complex logic in object building
process.

Costs and Disadvantages of Builder Pattern

Though Builder pattern reduce some line of code buy eliminating the need of setter methods, still
in double up total lines by introducing the Builder object. Furthermore, although client code is
more readable, the client code is also more verbose. Though for me, readability weighs more
than lines of code.