design patterns.pptVIP

Observer Example: MVC Subject Register(Observer) Unregister(Observer) NotifyAll() Observer virtual OnUpdate() for all o in observers { o.OnUpdate() } Controller View virtual OnUpdate() Chain of Responsibility Handler handleRequest() ConcreteHandler2 handleRequest() Client ContextInterface() ConcreteHandler1 handleRequest() Decouple sender of a request from receiver Give more than one object a chance to handle Flexibility in assigning responsibility Often applied with Composite successor Chain of Responsibility Example: handling events in a graphical hierarchy Figure handleEvent(Event) CompositeFigure Interactor children 0..* If interactor != null interactor.handle(event,this) else parent.handleEvent(event) 0..1 parent handle(Event,Figure) 0..* Concluding Design Patterns (GoF) provide a foundation for further understanding of: Object-Oriented design Software Architecture Understanding patterns can take some time Re-reading them over time helps As does applying them in your own designs Q A * Design Patterns Purpose A design pattern captures design expertise –patterns are not created from thin air, but abstracted from existing design examples Using design patterns is reuse of design expertise Studying design patterns is a way of studying how the “experts” do design Design patterns provide a vocabulary for talking about design Why design patterns in SA? If you’re a software engineer, you should know about them anyway There are many architectural patterns published, and the GoF Design Patterns is a prerequisite to understanding these: Mowbray and Malveau – CORBA Design Patterns Schmidt et al – Pattern-Oriented Software Architecture Design Patterns help you break out of first-generation OO thought patterns Patterns vs “Design” Patterns are design But: patterns transcend the “identify classes and associations” approach to design Instead: learn to recognize patterns in the problem space and translate to the solution Patterns can capture OO design principles with