information systems design
sicario
patterns__latestcontd_1.pptxPatterns (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
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”
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
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.
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
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 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 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? Which building block of OOP is used by Design Patterns? Why?
