Five Principles (revisited) Design Patterns: Background
1. Single-Responsibility Principle z Architectural design patterns 1. Single-Responsibility Principle { Christopher Alexander et al.: A Pattern Language, 1977 { Christopher Alexander: The Timeless Way of Building, 2. Open–Closed Principle 1979 3. Liskov Substitution Principle z World consists of repeating instances of various patterns 4. Depency-Inversion Principle { a pattern is (possibly hidden) design know-how that 4. Depency-Inversion Principle should be made explicit { ‘a quality without name’: not measurable but 5. Interface-Segregation Principle recognizable z User-centred design { capture the quality in a pattern language { inhabitants should design their own buildings together with a professional using the patterns
Alexander’s Patterns Alexander’s Patterns (cont’d) z What do high-quality contructs have in common? ‘Each pattern describes a problem which z Structures cannot be separated from the occurs over and over again in our problems they are solving environment, and then describes the core z Similarities in the solution structures → a pattern of the solution to that problem, in such a z Each pattern defines subproblems solved by other smaller patterns way that you can use this solution a z A pattern is a rule that expresses a relation million times over, without ever doing it between the same way twice.’ { a context { a problem and – C. Alexander, The Timeless Way of { a solution Building, 1979
Software Design Patterns Software Design Patterns (cont’d)
‘[Patterns] are descriptions z Reusable solutions to general design problems of communicating objects and classes that are z Represent solutions to problems that arise when customized to solve a developing software within a particular context general design problem in a particular context.’ { design pattern = problem–solution pair in a context { basic steps remain the same but the exact way of ‘A design pattern names, applying a pattern is always different abstracts, and identifies z Capture well-proven experience in software the key aspects of a common design structure development that make it useful for { static and dynamic structure creating a reusable object- { collaboration among the key participants oriented design.’ z Facilitate the reuse of successful software – E. Gamma (1995): architectures and designs
1 Definition of a Design Pattern Motivation
AA generalgeneral solutionsolution toto aa z Reusing the solutions { learn from other good designs, not your own mistakes frequentlyfrequently occurringoccurring { architectural building blocks for new designs architecture/designarchitecture/design problemproblem inin aa z Estabishing a common terminology { communication and teamwork context.context. { documenting the system z Giving a higher-level perspective on the problem z Not specific to any language, environment etc. and the process of design and object orientation z Described as a semiformal document { articulate the design rationale z Addresses a common problem { make hidden design knowledge explicit and available z Can be applied at architecture or detailed design level { name and explicate higher-level structures which are z Appears in a context that defines certain requirements or z Appears in a context that defines certain requirements or not directly supported by a programming language forces
The ‘Gang-of-Four’ Design Patterns Describing a Design Pattern z Gamma et al. describe and document 23 design Name Increases the design vocabulary patterns using a semi-formal procedure z GoF patterns are Intent The purpose of the pattern { not very problem-specific Problem Description of the problem and its context, { small and low-level patterns Problem { small and low-level patterns presumptions, example { focusing on flexibility and reuse through decoupling of classes Solution How the pattern provides a solution to the problem in the context in which it shows up z Underlying principles Participants The entities involved in the pattern { program to an interface, not to an implementation { favour composition over inheritance Consequences Benefits and drawbacks of applying the design { find what varies and encapsulate it pattern; investigates the forces at play in the pattern Implementation Different choices in the implementation of the design pattern, possibly language-dependent
Benefits of Design Patterns Design Patterns – the Flip Side
z Patterns are not without potential problems zPatterns improve developer { design fragmentation: more classes, more complicated communication dependencies { overkilling problems zPatterns enhance understanding by { excessive dynamic binding, potentional performance problem { ‘object schitzophrenia’, splitting objects documenting the architecture of a { wrong design pattern can cause much harm z Integrating patterns into a software development process is system a human-intensive activity zPatterns enable large-scale reuse of { not a piece of ready-to-use code zPatterns enable large-scale reuse of { can be implemented in many ways software architectures { not a general remedy to improve your system z Patterns can be deceptively simple zPatterns do not provide solutions, { condensed and abstracted experience and wisdom they inspire solutions! z Patterns are not written in stone! { reject or modify them to suit your needs
2 Design Patterns: Set 1 COMMAND zCOMMAND and ACTIVE OBJECT «interface» Sensor zTEMPLATE METHOD and STRATEGY Command zFACADE and MEDIATOR +do() zSINGLETON and MONOSTATE zNULL OBJECT
RelayOn MotorOn ClutchOn Command Command Command
RelayOff MotorOff ClutchOff Command Command Command
COMMAND (cont’d) ACTIVE OBJECT: Example z A function object; a public interface Command { method wrapped in an public void execute(); } object } z The method can be passed «interface» public class ActiveObjectEngine { to other methods or Command private List
TEMPLATE METHOD and STRATEGY TEMPLATE METHOD and STRATEGY (cont’d) z Defines the skeleton of an z Defines a family of algorithm algorithms Application { some steps are deferred { encapsulated, Application «interface» to subclasses interchangeable +run() +run() Runner Application { subclasses redefine the { algorithm can vary #init() steps without changing independently from #idle() +run() +init() the overall structure clients that use it #cleanup() +idle() z Used prominently in z Identify the protocol that +cleanup() frameworks provides the level of z Cf. java.applet.Applet, abstraction, control, and javax.swing.JApplet interchangeability for the Implementation client → abstract base class z All conditional code → #init() Strategy1 Strategy2 Strategy3 concrete derived classes #idle() #cleanup()
3 FACADE FACADE (cont’d)
z A unified interface to a set of interfaces in a subsystem Client Facade {encapsulates a complex subsystem within a single interface object +operation1() +operation2() {makes the subsystem easier to use … z Decouples the subsystem from its clients {if it is the only access point, it limits the features and flexibility Database z Imposes a policy ‘from above’ Driver Connection Statement {everyone uses the facade instead the Manager subsystem Prepared SQL {visible and constraining ResultSet Statement Exception
MEDIATOR SINGLETON: Example z Imposes a policy ‘from public class Singleton { below’ { hidden and private static Singleton unconstraining theInstance = null; z Promotes loose coupling JList JTextField { objects do not have to refer to one another private Singleton() { /* nothing */ } { simplifies communication z Problem: monolithism z Example: public static Singleton create() { QuickEntryMediator if (theInstance == null) { binds text-entry field to a «anonymous» QuickEntry list Document theInstance = new Singleton(); Mediator { when text is entered, the Listener first element matching in return theInstance; the list is highlighted } }
MONOSTATE: Example Comparison public class Monostate
4 NULL OBJECT NULL OBJECT: Example
public interface Employee { public boolean isTimeToPay(Date payDate); public void pay();
«interface» public static final Employee NULL = Application Employee new Employee() { public boolean isTimeToPay(Date payDate) { return false; } public void pay() { /* nothing */ } «creates» Employee NullEmployee }; Implementation }
«creates»
Reading for the Next Week zSection 4: Packaging the Payroll System {Chapter 20: Principles of Package Design {Chapter 21: FACTORY {Chapter 22: The Payroll Case Study (Part 2)
5