information systems design
sicario
lesson_2_patterns_2.pptxObserver 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
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
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
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 Solution:
Use Interfaces
Composition vs. Inheritance
Planning for change
How big does a project have to be?
Separate the most changeable parts of your code
Easy maintenance.
Reuse the changeable parts
In inheritance, base classes and derived classes have an “is-a” relationship.
Helicopter “is-a” Vehicle
The base class handles a particular task one way, but then a derived class changes that, and the next derived class down the line changes things yet again
Result handling a task is spread over several classes
Composition vs. Inheritance
Solution: Extract the volatile parts of your code and encapsulate them as objects
Entire task is handled by the code in such an object
Create composites of objects. Select and use the objects as needed
A “has-a” relationship with those objects
A street racer “has-a” way of moving; a helicopter “has-a” way of moving etc.
Composition vs. Inheritance
To ensure any algorithm can be used by any
Vehicle, all algorithms should implement this
interface
Algorithms separated from code.
“has-a” instead of “is-a” design techniques
Composition vs. Inheritance
Create an object from the algorithm
Store that object
New method to the Vehicle base class,
setGoAlgorithm.
Method stores the algorithm in an internal,
private variable, goAlgorithm
To use a particular algorithm in a derived class,
call the setGoAlgorithm method with the
correct algorithm object
Composition vs. Inheritance
Composition vs. Inheritance
Composition vs. Inheritance
The Strategy Pattern
Creating a family of algorithms lets you choose your strategy
Design pattern is often used as an alternative to inheritance
Extract the volatile parts of your code and encapsulate them as objects. Customize your code by creating composites of objects. At runtime, use polymorphism to choose the object(s) you want to work
The Strategy Pattern
Use the Strategy design pattern
Volatile code that can be separated out of
Avoid handling a task by splitting implementation code over several inherited classes.
The algorithm used for a task at runtime changes
