The document discusses various design patterns used in software development to manage changes and improve code maintainability, including the Strategy, Decorator, Factory, Observer, Singleton, Flyweight, Adapter, and Facade patterns. Each design pattern provides a solution to specific issues related to code modification and extensibility, advocating for principles such as loose coupling and encapsulation. It emphasizes the importance of composition over inheritance in object-oriented programming, particularly for managing complex systems and maintaining flexibility.

1. Patterns (contd)
Software Development Process
Design patterns used to handle change
More time extending and changing code than developing it.
The Strategy design pattern handle change by selecting from a
family of external algorithms rather than rewrite.
Design point: Make code closed for modification of code, but
open for extension
Problem
Computer object created
Description Method returns
Getting a Computer
Problem
Program has to change every time
Customer changes options
Decorator Pattern
Wrapper code used to extend your core code
Extend a class dynamically at runtime
Decorator uses wrapper code to extend core functionality -
decorating the code
Decorator Pattern

2. description() returns “You are getting a computer”
Wrapper description() returns
“You are getting a computer and a disk”
Wrapper description() returns
“You are getting a computer and a disk and a monitor”
Decorator Pattern
Core component: Computer
Variables holding computer objects should also be able to hold
objects that wrap computer objects.
Extend the wrapper classes from the Computer class.
Abstract class cannot be instantiated
Ensures all wrappers are consistent
Developers have to provide their own description
Decorator Pattern
Method calls the core computer object’s
description method and adds “and a disk”
Decorator Pattern
Method calls the core computer object’s
description method and adds “and a disk”

3. Extend the core object by wrapping it in decorator wrappers.
Avoids modification of the core code.
Each successive wrapper called the description method of the
object it wrapped and added something to it.
Factory Pattern
Based on type, call the
Connection method
Factory Pattern
Create a method that returns the
correct connection type
Factory Pattern
New operator used to create OracleConnection objects.
New operator used to create SqlServerConnection objects, and
MySqlConnection objects.
New operator to instantiate many different concrete classes
Code becomes larger and needs to be replicated in many places
Factor that code out into a method.
Code keeps changing
Encapsulate code into a factory object
Goal: Separate out the changeable code and leave the core code
closed for modification

4. Building the Factory
Creating the Factory
FirstFactory class encapsulates the connection object creation
Pass to it the type of connection (“Oracle”, “SQL Server”,)
Use the factory object to create connection objects with a
factory method named createConnection
Building the Factory
Create the FirstFactory class.
Save the type of the database, passed to the FirstFactory class’s
constructor.
Object-creation code changes
Check which type of object to be created
(OracleConnection, SqlServerConnection,
and then create it.
Factory Class
Create the Abstract Connection Class
Core code should not be modified or has to be modified
as little as possible.
Using the connection object returned by the
new factory object
Use the same code for all the different types of
connection objects
Code should be polymorphic — all connection objects
should share the same interface or be derived from
the same base class.

5. Able to use the same variable for any created object
Make the Connection Class Abstract
Derive all the objects your factory creates from the
same base class or interface
Code that uses the objects it creates doesn’t have to be
modified for each new object type.
Creating Concrete Connection Class
Testing it Out
The Observer Pattern
Subject informs a set of Observers about a Change or Event
The Observer Pattern
The Observer Pattern
Chain of Responsibility Pattern

6. Coupling
The Observer and Chain of Responsibility design patterns
implement loose coupling
Hard coding command handling results in a large, monolithic
class that’s hard to debug or even understand.
Encapsulated objects through simple notifications rather than
hard coding a connection.
Flexibility and robustness.
Self-contained objects: easier to debug and develop semi-
independent objects
Design Guideline: loose coupling between objects, rather than
extending objects is good design policy
Singleton Pattern
Singleton design pattern only one object of a particular class
throughout your code
New operator just keeps on creating more and more objects of
the same class
Use the Singleton design pattern when you want to restrict
resource use or when you have an object whose data shouldn’t
be accessed by multiple instances (such as a registry or multi-
threading).
Singleton Pattern
Singleton pattern creates only one object from a specific class

7. irrespective of number of times your code tries to create it.
Sensitive objects where conflicts cannot be permitted
Example: windowsRegistry.
Singleton pattern takes control over the object instantiation
process away from the new operator
Flyweight Pattern
The Flyweight pattern
Code uses many large objects — using up system resources
Fix by using a smaller set of template objects configured on-
the-fly (run time) to look like those larger objects.
The configurable objects — the flyweights — are fewer, smaller
and reusable
After configuration they will appear to the rest of your code as
though you still have many large objects.
Flyweight Pattern
Flyweight Pattern
Takes time to configure a flyweight object,
If configurations are constantly changing, lose much of the
performance gains.
Extracting a generic template class from existing objects in
order to create flyweight objects
Adding a layer of programming, which make maintenance and
extension harder.
Adapter Pattern
The Adapter design pattern fixes the interface between objects
and classes without having to modify the objects or classes

8. directly.
Off-the-shelf solution cannot change what one application
produces to make it compatible to another application.
Adapter Pattern
Façade Pattern
The Facade design pattern makes an OOP interface easier to
use.
If an object or class interface is too hard to work with, the
Facade pattern gives you a front end to that interface to make it
easier.
facade simplifies the interface between a class or object and the
code that makes use of that class or object
Façade Pattern
For effective OOP, classes of objects should not have to know
too much about each other.
Details should be inside each class or object and make the
coupling between entities as loose as possible
If an object needs to know too much about another make their
coupling loose by using a Facade pattern
Quiz
What are the building blocks of Object Oriented Programming
(OOP)? Why are Design Patterns used in developing systems?

9. Which building block of OOP is used by Design Patterns?
Why?
Observer Pattern
Pass notifications when an event occurs
Java Event notifications
Object Oriented Programming
General principle: break up programs into manageable units
Functional programming: break into functions
Insufficient for large programs:
Solution
to break programs into objects, incorporate functions
(behavior) within object description
Wrapping functionality into objects makes them easy to
conceptualize
Display wraps the display function of your program into the
object
Database all the database connectivity

10. OOP Building Blocks
Abstraction
Encapsulation
Polymorphism
Programs that can handle different object types at run time
Inheritance
One class inherit methods and properties from another
Design Oriented Programming
Polymorphism preferred since design patterns tend to favor
composition over inheritance.
Inheritance make code rigid making maintenance difficult.
Design oriented programming uses composition objects contains
other objects
Composition vs. Inheritance
Task: Design New Classes of Vehicles
Method: Indicates the Driving mode
Street Racer extends Vehicle

11. Invoke Method: Shows the Driving mode
Composition vs. Inheritance
New Class: Formula One racer
Composition vs. Inheritance
New Class: Helicopter
Problem: A single task is accomplished — driving a car or
flying a helicopter — across several generations of classes
Tasks that change often result in having to edit several classes
becomes a maintenance issue.
Tip: avoid spreading out the handling of a particular,
changeable tasks over several generations of classes

12. Composition vs. Inheritance
Problem
Each class and subclass still has to implement its own version
of the go method
Interfaces require custom code in each class
Possible