Geeknight 9.0 edition presentation on object oriented design principles.

1. Design Patterns
Sarat Kongara
Lazy Programmer, www.LeapZen.com

2. The only thing that is certain in
software is CHANGE.
In this world nothing can be
said to be certain, except death
and taxes.

3. Highly Cohesive
Loosely Coupled
Easily Composable
Context Independent
Object Oriented Design

4. Encapsulate what varies
Favor composition over inheritance
Program to interfaces, not implementations
Strive for loosely coupled designs
Depend on abstractions
Only talk to your friends
Don’t call us, we’ll call you
OO Design Principles

5. Single responsibility
Open close principle
Liskov substitution
Interface segregation
Dependency inversion
SOLID Design Principles

6. Each pattern describes a problem which
occurs over and over again in our
environment, and then describes the core
of the solution to that problem, in such a
way that you can use this solution a million
times over, without ever doing it the same
way twice - Christopher Alexander.
Definition

7. Reuse solutions
Establish common terminology
Gain higher-level perspective on the problem
and on the process of design and object
orientation.
Why study design patterns

8. Problem #1
PartyPoker - online multi-player poker
game

9. Player Avatar
Different card layouts for multiple game
types: Texas Hold’em, Pot-limit Omaha,
Omaha Hi-Lo, 7 Card Stud.
What varies - The logic of showing the cards
(face-up, face-down, number, size etc)

10. Strategy Pattern
Define a family of algorithms, encapsulate each one, and
make them interchangeable. Lets the algorithm vary
independently from clients that use it.

11. Strategy Pattern
Consequences
Families of related algorithms
An alternative to subclassing
Strategies eliminate conditional statements

13. Problem #2
Transformation - Mechanical Design
Automation of a distribution transformer
Different CAD applications have different APIs to generate
a 3D model from a parametric model.
The steps involved in generating the model vary from one
CAD application to another.
What varies - The specification (steps) and
the implementation (API calls) vary in this
case.

14. Bridge Pattern
Decouple an abstraction/interface from its implementation
so that the two can vary independently.

15. Consequences
Decoupling interface and implementation. Bound at run time.
Improved extensibility
Hiding implementation details from clients
Bridge Pattern

16. Abstraction
Launch and connect
Set working directory
Open model
Set parameters
Regenerate model
Regenerate drawing
Close model
Update part files
Update assembly files
Quit
Implementations
Inventor
SolidWorks
Creo
CAD Application Proxy
public void GenerateCADFiles()
{
try
{
CreateWorkingDirectory();
CopyCADFilesToWorkingDirectory();
ConvertDesignParametersToUseCADNamingConvention();
UpdateExcelDesignParameterFiles();
LaunchAndConnect();
SetWorkingDirectory();
UpdatePartFiles();
UpdateAssemblyFiles();
UpdateDrawingFiles();
OpenMainAssembly();
RegenerateMainAssembly();
SaveMainAssembly();
Quit();
}
catch (CADCommandException exception)
{
Debug.WriteLine(exception.ErrorMessage);
}

17. Problem #3
LeapZen - Telephonic Interview bridge call
Automated call to the applicant at the scheduled time.
Play message and ask the applicant to hold the line.
Dial the employer/interviewer (bridge call)
Play the audio introducing both the participants.
Start the interview.
Call can get interrupted at anytime.
What varies - What to do next depends on
the current state/status of the call.

18. State Pattern
Allow an object to alter its behavior when its internal state
changes. The object will appear to change its class.

19. State Pattern
Consequences
It localizes state-specific behavior and partitions behavior for
different states
It makes state transitions explicit
State objects can be shared

20. Context
InPersonInterview
ConcreteStates
BridgeCallPendingState
BridgeCallInProgressState
BridgeCallDeclinedByApplicantState
BridgeCallEmployerNotReachableSta
te
BridgeCallDeclinedByEmployerState
BridgeCallCompletedState
Events
dial_out
dial
dial_start
hangup

21. Choosing a Design Pattern

22. References
Head First Design Patterns
by Kathy Sierra and Eric Freeman
Design Patterns - Elements of Reusable
Object-Oriented Software
by GOF (Eric, Richard, Ralph and John)
Design Patterns Explained
by Allan Shalloway