1 / 34

Software Engineering Lecture 7 - Design Patterns

Learn the importance and application of design patterns in software engineering. Explore key patterns like Singleton and Factory Method with real-world examples. Understand how patterns improve code quality and maintainability.

tlederman
Download Presentation

Software Engineering Lecture 7 - 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. Software EngineeringLecture 7- Design Patterns

  2. Agenda • Short introduction to the assignment • Small introduction to important terms • What is a design pattern and why use them? • Presentation of a few patterns • Singleton • Factory Method • Abstract Factory

  3. About the assignment • Goal • Learn about different patterns • Learn how to apply patterns • Task • Read about the patterns • Identify 3 patterns that are used in your project • Describe how they are implemented

  4. Useful terms 1(4) • Signature • Interface • Type • Instance • Encapsulation

  5. Useful terms 2(4) • Inheritance • Override • Composition • Dynamic binding • Polymorphism

  6. Useful terms 3(4) • Abstract vs concrete • Interface vs class • Inheritance vs composition • Composition and delegation

  7. Useful terms 4(4) • Aggregation vs acquaintance • Run-time vs compile-time structures • Toolkit vs framework

  8. What is a design pattern? "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, NY 1977

  9. Why use design patterns? ”One way to measure the quality of an object-oriented system is to judge whether or not its developers have paid careful attention to the common collaborations among its objects. Focusing on such mechanisms during a system’s development yields an architecture that is smaller, simpler, and far more understandable than if these patterns are ignored.” -- Grady Booch

  10. cont. Why use design patterns? • Proven • Reusable • Expressive “Software entities should be open for extension but closed for modification” ”Program to an interface not an implementation” ”Favour composition over inheritance”

  11. Three kinds of patterns • Creational – Abstract Factory, Builder, Factory Method, Prototype, Singleton • Structural – Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy • Behavioral – Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

  12. Scenario

  13. Alipes • A platform encapsulating several different positioning-techniques • One simple interface for all different techniques • Keeps device specific implementation away from application developers

  14. Singleton

  15. Singleton -- problem • Ensure only one instance of a class • Defining everything static is a bad idea • Not flexible • Not encapsulated

  16. Singleton -- solution • Let a static method return itself • Create if non-existing • Singleton ensures only one instance • Only requires one static method

  17. Singleton -- UML Singleton Return uniqueInstance + Instance() : Singleton Underlined means static + SingletonOperation() + GetSingletonData() : singletonData + uniqueInstance() : Singleton singletonData

  18. Singleton -- example • Alipes example • A server opens a port on the network • Listens for commands on the opened port • Can only have one instance of the server • Use singleton

  19. Singleton – example cont. 01. public Singleton { 02. // private instance 03. private static Singleton uniqueInstance; 04. 05. // private constructor 06. private Singleton() { 07. } 08. 09. // instantiationmethod 10. public static Singleton Instance() { 11. if (uniqueInstance == null) 12. uniqueInstance = new Singleton(); 13. returnuniqueInstance; 14. } 15. ....

  20. Singleton -- usage • Consequences • Controlled access to a sole entity • Encapsulation • Reduced name-space • No global variables needed • More flexible than class operations • easier to change

  21. Factory Method

  22. Factory Method -- problem • Create and maintain several components • The class can’t anticipate the class of objects it must create • Hardcoding which components to use is a bad idea • Requires constant changing • Not using a common interface is bad • Makes the code hard to read

  23. Factory method -- solution • Define a common interface for the components • Let subclasses decide which to instantiate • Factory Method defers instantiation to subclasses

  24. Factory Method -- UML Product Creator + FactoryMethod() : Product + AnOperation() ConcreteProduct ConcreteCreator + FactoryMethod() : ConcreteProduct

  25. Factory Method - example • Alipes example • Several positining-tecniques • Available positining services vary between devices • Factory Method • Create a common interface (PushPositionDevice) • Implement support for a positioning-technique, implement the PushPositionDevice interface • Let the factory instantiate the necessary positioning-devices

  26. Factory Method – example cont. 01. public interface PushPositionDevice extends PositionDevice { 02. public voidaddPositionListener(PositionListener pl); 03. } 04. 05. public class DeviceManager implements PositionListener { 06. synchronized voidloadAllDevices() { 07. String[] deviceClasses = getDevices(); 08. 09. for (int i=0; i < deviceClasses.length; i++) { 10. try { 11. Class c = Class.forName(deviceClasses[i]); 12. // open up the device 13. PushPositionDevice pd = (PushPositionDevice) c.newInstance(); 14. } 15. } catch (Exception err) { 16. } 17. // …} // …}

  27. Factory method -- usage • Consequences • Makes dynamic architectures possible

  28. Abstract Factory

  29. Abstract Factory - Problem • Ex: You want to be able to easily change the look-and-feel of your user interface (not hard coding it) • Bad solution – Instantiating with concrete classes throughout the application: • UnixWindow w = new UnixWindow();

  30. Client Abstract Factory B2 B1 AbstractA A1 A2 AbstractB +CreateA(): AbstractA +CreateB(): AbstractB ConcreteFactory1 +CreateA(): A +CreateB(): B ConcreteFactory2 +CreateA(): A +CreateB(): B Abstract Factory - Solution

  31. Client Abstract Factory MacScrollbar UnixScrollbar AbstractWindow UnixWindow MacWindow AbstractScrollbar +CreateWindow(): AbstractWindow +CreateScrollbar(): AbstractScrollbar UnixFactory +CreateWindow(): UnixWindow +CreateScrollbar(): UnixScrollbar MacFactory +CreateWindow(): MacWindow +CreateScrollbar(): MacScrollbar Abstract Factory – Solution

  32. Abstract Factory - Applicability • When a system should be • independent of product creation, composition and representation • configured with one of multiple families of products • When a family of related product objects are designed to be used together • When you want to provide a class library revealing only interfaces and not implementation

  33. Abstract Factory - Consequences • Isolates concrete classes • Makes exchanging product families easy • Promotes consistency among products • Supporting new kinds of products is difficult

  34. Thank you for listening, see you next time!

More Related