1 / 24

Design Patterns

Design Patterns. ECE 417/617: Elements of Software Engineering. Stan Birchfield Clemson University. What is a Design Pattern?. A design pattern abstracts a recurring design structure comprises class and/or object dependencies, structures, interactions, or conventions

susane
Download Presentation

Design Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design Patterns ECE 417/617:Elements of Software Engineering Stan Birchfield Clemson University

  2. What is a Design Pattern? • A design pattern • abstracts a recurring design structure • comprises class and/or object • dependencies, • structures, • interactions, or • conventions • distills design experience

  3. Re-use • Code re-use • Don’t reinvent the wheel • Requires clean, elegant, understandable, general, stable code • leverage previous work • Design re-use • Don’t reinvent the wheel • Requires a precise understanding of common, recurring designs • leverage previous work

  4. Some design patterns • Abstract factory • Adapter • Bridge • Command • Composite • Façade • Subject / Observer • Proxy • Strategy

  5. Subject-observer [from Vlissides]

  6. Subject-observer (cont.) 1 * Subject Register(Observer) Unregister(Observer) NotifyAll() Observer OnUpdate() for all o in observers { o.OnUpdate() }

  7. Subject-observer (cont.) 1 * Subject Register(Observer) Unregister(Observer) NotifyAll() Observer virtual OnUpdate() for all o in observers { o.OnUpdate() } ConcreteSubject ConcreteObserver virtual OnUpdate()

  8. Model / view / controller (MVC) (displays data) View { Model m; Controller c(&m); View v(&c); } (mediates) Controller (holds data) Model calls Register() Main Create() View Create() Register() Create() Controller Model

  9. MVC (cont.) 1 * Subject Register(Observer) Unregister(Observer) NotifyAll() Observer virtual OnUpdate() for all o in observers { o.OnUpdate() } Controller View virtual OnUpdate()

  10. MVC (cont.) class Observer { protected: virtual void OnUpdate(MsgId message_id) = 0; }; class Subject { public: enum MsgId {}; void RegisterObserver(Observer* obs); virtual void NotifyAllObservers(MsgId message_id) { for (int i=0 ; i<m_observers.size() ; i++) { m_observers[i]->OnUpdate(message_id); } } private: std::vector<Observer*> m_observers; };

  11. MVC (cont.) class Controller : public Subject { Controller(Data* d) : m_data(d) {} const Data* GetData() const; void AddSphere(const Sphere& s) { m_data->AddSphere(s); NotifyAllObservers(ADD_SPHERE); } private: Data* m_data; };

  12. MVC (cont.) class MainWnd : public Observer { public: MainWnd(Controller* c) : m_controller(c) { c.Register(this); } virtual void OnUpdate(int message_id) { switch (message_id) { case Subject::ADD_SPHERE: ... } } private: Controller* m_controller; };

  13. Adapter • You have • legacy code • current client • Adapter changes interface of legacy code so client can use it • Adapter fills the gap b/w two interfaces • No changes needed for either • legacy code, or • client

  14. Adapter (cont.) class NewTime { public: int GetTime() { return m_oldtime.get_time() * 1000 + 8; } private: OldTime m_oldtime; };

  15. Command • You have commands that need to be • executed, • undone, or • queued • Command design pattern separates • Receiver from Invoker from Commands • All commands derive from Command and implement do(), undo(), and redo()

  16. Facade • You • have a set of related classes • want to shield the rest of the system from these details • Facade provides a simplified interface • Encapsulates a subsystem

  17. Composite • You want uniformly to treat • items (atomic elements), and • groups (containing items or other groups) • Composite interface specifies operations that are shared between items and groups • Examples: hierarchy of files and directories, groups of drawable elements

  18. Composite (cont.) Composite Item Group

  19. Proxy • You want to • delay expensive computations, • use memory only when needed, or • check access before loading an object into memory • Proxy • has same interface as Real object • stores subset of attributes • does lazy evaluation

  20. Strategy • You want to • use different algorithms depending upon the context • avoid having to change the context or client • Strategy • decouples interface from implementation • shields client from implementations • Context is not aware which strategy is being used; Client configures the Context • strategies can be substituted at runtime • example: interface to wired and wireless networks

  21. Strategy (cont.) Client Policy Strategy Context Concrete StrategyA Concrete StrategyB

  22. Bridge • You • have several different implementations • need to choose one, possibly at run time • Bridge • decouples interface from implementation • shields client from implementations • Abstraction creates and initializes the ConcreteImplementations • Example: stub code, slow code, optimized code

  23. Bridge (cont.) Client Implementor Abstraction Concrete ImplementorA Concrete ImplementorB Refined Abstraction

  24. Design pattern space [from Vlissides]

More Related