Design PatternsSarat Kongara

Lazy Programmer, www.LeapZen.com

The only thing that is certain in software is CHANGE.

In this world nothing can be said to be certain, except death and taxes.

Highly CohesiveLoosely Coupled

Easily ComposableContext Independent

Object Oriented Design

Encapsulate what variesFavor composition over inheritance

Program to interfaces, not implementations

Strive for loosely coupled designsDepend on abstractionsOnly talk to your friends

Don’t call us, we’ll call you

OO Design Principles

Single responsibilityOpen close principleLiskov substitution

Interface segregationDependency inversion

SOLID Design Principles

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

Reuse solutionsEstablish common terminologyGain higher-level perspective on the problem and on the process of design and object orientation.

Why study design patterns

Problem #1PartyPoker - online multi-player poker game

Player AvatarDifferent 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)

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

Strategy Pattern

ConsequencesFamilies of related algorithmsAn alternative to subclassingStrategies eliminate conditional statements

Problem #2Transformation - 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.

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

ConsequencesDecoupling interface and implementation. Bound at run time.Improved extensibilityHiding implementation details from clients

Bridge Pattern

AbstractionLaunch and connectSet working directoryOpen modelSet parametersRegenerate modelRegenerate drawingClose modelUpdate part filesUpdate assembly filesQuitImplementationsInventorSolidWorksCreo

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); } }

Problem #3LeapZen - Telephonic Interview bridge callAutomated 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.

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

State Pattern

ConsequencesIt localizes state-specific behavior and partitions behavior for different statesIt makes state transitions explicitState objects can be shared

ContextInPersonInterview

ConcreteStatesBridgeCallPendingStateBridgeCallInProgressStateBridgeCallDeclinedByApplicantStateBridgeCallEmployerNotReachableStateBridgeCallDeclinedByEmployerStateBridgeCallCompletedState

Eventsdial_outdialdial_starthangup

Choosing a Design Pattern

ReferencesHead First Design Patternsby Kathy Sierra and Eric Freeman

Design Patterns - Elements of Reusable

Object-Oriented Softwareby GOF (Eric, Richard, Ralph and John)

Design Patterns Explainedby Allan Shalloway