This presentation shows some basics of design patterns and explanation of some common used design patterns such as Singleton, Observer, Command, etc.

1. Design Patterns Don’t reinvent the wheel Hanoi - April, 2009 Duong Trong Tan, (tandt@fpt.edu.vn)

2. What are design patterns? They are common ways of structuring programs typically deal with a small number of classes, but can be of any size provide a communication framework in which ideas can be discussed at a high level can specify how objects are created, how they interact, or how they are structured

3. Why design patterns? Reuse solutions Vocabulary for development Better software

4. Who? Alexandre Christopher ‘Gang of Four’: Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides

5. What? Gang of Four common design patterns Some new J2EE design patterns

7. Favor composition over inheritance

8. Encapsulate what varies

9. Strive for loosely coupled between objects that interact

10. Classes should OPEN for extension and CLOSE for modification

11. Depends on abstraction, not concrete classes

12. Don't call us, we'll call you

15. Singleton public static Counter getInstance() { if(uInstance == null) { this.uInstance = new Counter(); return this.uInstance; } else { return this.uInstance; } } C

16. The purpose of Singleton Makes sure only one instance of an object exists within an application. A better solution compared to global variables Provide global access to the object instance. Example: Counter, Application Menu System, Application objects, Services, Clients Not as easy as you think: What about threading?

17. Factory Method Defines an interface for creating an object but lets subclasses decide which class to instantiate. Lets classes defer instantiation to subclasses C

18. Benefits of Factories We can choose what to instantiate at runtime We can code to an interface Don’t have to know exactly what kind of object we’ll get back We centralize code In order to add new types of objects, we only have to modify one place, the factory 12

19. Builder C Separate the construction of a complex object from its representation so that the same construction process can create different representations.

20. Façade S Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. (GoF)

21. The DBFacade Example Common JDBC uses: Open a connection to DB Close a connection Get all tables from DB Executes a SQL statement Retrieve result from a SELECT statement All That I Need

22. DatabaseFacade Outlook Client uses DatabaseFacade JDBC API Connection ResultSet ResultSetMetadata Statement DatabaseMetadata Driver …

23. Decorator S BufferedReader in = new BufferedReader(new FileReader(“foo.in"));

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

25. Observer B Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. GoF

26. MVC What does it hire?

27. Command B “Let’s hide (encapsulate) the way we call (invoke) methods.”

28. Example: Menus Consider an application menu system. How do we de-couple our menu system from our document class? Composite Pattern! Menu contains many menu items. ConcreteCommand Client invoker We can do a lot of things (actions) with a document. Each interface might be different! Command Interface Receiver

29. AllGoFpatterns

31. Business Tier

33. Business Objects Alur et al.

34. Session Façade Alur et al.

35. Application Service Alur et al.

36. References E. Gamma, R. Helm, R. Johnson, & J. Vlissides. Design Patterns: Elements of Object-Oriented Software. Addison-Wesley, Boston, 1995. D. Alur, J. Crupi and D. Malks, Core J2EE Patterns: Best Practices and Design Strategies, Second Edition, 2003