Welcome to Design Patterns

NMX ITians DEN

 Welcome to Design Patterns
• Someone has already solved your problems.
– load your brain with patterns
– recognize places in your designs and existing
applications
– Instead of code, get experience reuse
 Why we need design patterns?
• Do we really need to know design patterns
– Can we always created good OOD; as long as we
follow encapsulation, know about abstraction,
inheritance, and polymorphism?
– Can we build reusable, flexible and maintainable
systems by just knowing OO basics.
• Design patterns give us sometimes non-
obvious ways of constructing object-oriented
systems
SimUDuck App
 Change Request
• Simulate ducks flying behavior
Demo
 What happened
• Failed to notice that not all subclasses of duck
should fly.
• A localized update to the code caused a non-
localized side effect (flying rubber ducks)
• The great use of inheritance for the purpose
of reuse hasn’t turned out so well when it
comes to maintenance.
Class Diagram

Rubber ducks
don’t quack,
so quack () is
overridden to
Squeak”
Inheritance….
 Food for thought
• What are disadvantages of using inheritance?
How about an interface
Code duplication
 CHANGE
• Change is the only constant in software
development
• Code always needs change
• Build software such that change has
– Least possible impact on existing code
– Need less time for reworking
 Design Principle 1
• 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 rest of your code
• Result? Fewer unintended consequences from code
changes and more flexibility in your systems
 Separating what varies from what
stays the same
• Fly() and Quack() vary across all the ducks
 Design Principle 2
• Program to an interface, not an
implementation.

• Interface here is not a java interface.

• “Program to an interface”, means
“program to a supertype”
 Programming to an interface
Dog d = new Dog();
d.bark();

Animal animal = new Dog();

animal.makeSound();
• Assign concrete implementation object at
runtime.
animal = getAnimal();
animal.makeSound();
Implementing Duck Behaviors
Implementing Duck Behaviors
Integrating Behaviors
Integrating Behaviors
WHAT GIVES!!!
 Adding behavior
• At object construction
• At runtime. Changing behavior on the fly.
 HAS-A can be better than IS-A
• Each duck HAS-A FlyBehavior and
QuackBehavior to which it delegates flying
and quacking
• Instead of inheriting behavior, ducks get their
behavior by being composed.
 Design Principle 3
• Favor composition over inheritance

• Allows encapsulating a family of classes

into their own set of classes
• Allows changing behavior at runtime
 The STRATEGY Pattern
The strategy pattern defines a family
of algorithms, encapsulates each
one, and makes them
interchangeable. Strategy lets the
algorithm vary independently from
clients that use it.
 Quiz
• Inheritance (“extends”)
• Interface (“Implements”)
• HAS-A
Thank You

And
Be Happy!!!