1. C++ Training Datascope Lawrence D’Antonio Lecture 12 Design Patterns

2. What are patterns?  Patterns may be thought of as solutions to recurring problems.  They tell us what should be done when confronting a known problem in a given context.  Also, just as patterns tell us what to do, there exist anti-patterns which tell us what not to do in certain situations.

3. Origins of Patterns  The concept of patterns as playing a key role in the design process arises from the work of the architect Christopher Alexander.  For Alexander, the difference between good architecture and bad architecture is an objective one. Patterns are a way of capturing this difference.

4.  Patterns, with their emphasis on solutions to recurring problems, reveal underlying structure in the problem domain, support the principles of software reuse, and most importantly, generate solutions to problems.  Patterns show us at the same time the flashpoints of a system and what to do about them.

5.  Good design works to the benefit of its users. This human side to design, emphasizing its wholeness, harmony, completeness, endurance, and vitality, is too often overlooked (in buildings and in software).

6. Christopher Alexander

7. Alexander’s Books

9. Alexander’s definition of pattern  “Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.”

10.  “The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it.“

11.  “It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing.”  Patterns establish relations between objects in particular contexts.  So that if the same context arises again then we expect to see the same relationships.

12. In short  "A pattern is a solution to a problem in context.“  Patterns establish relations between objects in particular contexts.  So that if the same context arises again then we expect to see the same relationships.

13. Simple example  "Where a freeway meets an artery the access ramps of the interchange take the rough form of a cloverleaf.“  The Interchange pattern explains to the architect how to build an interchange.

15. CS example  Call by Reference pattern  This pattern states that when large objects are passed on the stack (or small objects passed frequently) then the call should be done by reference rather than by value.  The Call by Reference pattern explains to the student programmer how to pass large objects.

16. Alexandrian Patterns  Patterns have the following components:  Problem, Context, Forces, Solution, Examples, Resulting Context, Rationale

17. Problem  A set of goals and objectives within a given context and with a given set of constraints. This describes the intent of the system.

18. Context  The initial state (or configuration) of the system prior to applying the pattern.  The pattern will solve the given problem only if it is applied in the appropriate context.  Once a pattern becomes known, the context is a signpost for applying the pattern.

19. Forces  A description of system constraints.  A good design pattern resolves these forces as far as possible.  The forces themselves are often in conflict and will need to be balanced in the final design.  This may result in trade offs among system objectives, criteria, and resources.

20. Types of forces  Resource forces (e.g., time vs. space)  Structural forces (e.g., reusability, modularity, extensibility)  Strategic forces (e.g., relationships to other software, maintenance issues)  System integrity forces (e.g., correctness, security, fault tolerance)  Human factor forces (e.g., aesthetics, learning curve, social impact)

21. Sample Questions  What forces constrain a word processor when opening a document?  What forces affect how a Web browser loads a Web page?  What are the most significant forces affecting a context-sensitive help system?

22.  The problem of handling different document types in an application can be resolved by having the application hold a reference to an abstract document type.

23.  Upon loading a document, that reference gets resolved to a concrete document type (which is a subtype of the abstract document class) or else the application displays a message such as "Document type not recognized".  This solution employs the Template Method pattern.

24. Solution  The resolution of the forces in the problem.  A pattern is not simply a strategy, algorithm, or heuristic.  Patterns are generative.  Patterns describe the creation of an object whose possession resolves the given forces.

25.  Patterns start with observation, not with theory.  One could argue that patterns are by nature metaphorical.  The best patterns solve problems by simply giving us a way of thinking about the problem.

26.  A specific pattern frequently found in GUI design is called Composite, which allows aggregate objects to be viewed as a tree hierarchy.  The Composite pattern works by creating a hierarchy for which some subobjects are atomic and other subobjects are themselves composite (hence giving a recursive structure to the hierarchy).

27.  At the root is the entire object, each node is a subobject. An atomic object will appear as a leaf in the hierarchy. This allows the designer to easily create nested visual objects (i.e., objects which are composed of other visual objects).

28. Examples  Also called Known Uses  Specific applications of the pattern.  This may include sample code and uses of the pattern in existing systems.

29. Resulting Context  The consequences of applying the pattern.  This gives the new state of the system, including the resolution of the forces in the initial context.

30. Rationale  A justification for the pattern. That is, it explains why the pattern works.

31. Types of Patterns  Patterns occur at different granularities.  That is, patterns can be found in structures ranging from entire organizations through large-scale software applications down to individual objects and program fragments.

32. Primary pattern types  Architectural  Design  Idioms  Programming  Organizational

33. Architectural Patterns  Architectural patterns describe system structure.  These patterns specify the components of a system, their responsibilities, and relationships.

34.  A well-known example of an architectural pattern is the Model-View-Controller (MVC) pattern used to build interactive applications.  The MVC pattern solves the problem of separating the application core from its presentation.

35.  The Model contains the underlying data and functionality of the application.  The View defines the visual display.  The Controller handles user input.

36. MVC Pattern  Pattern: Model-View-Controller (MVC)  Problem: How to coordinate data handling, presentation, and user input in an interactive application.  Context: Interactive, event-driven applications that couple the data model and view are difficult to adapt and modify.

37.  Forces: The application core should be independent of its presentation. This core should be reusable. The application should support different simultaneous views of the data. Adding new views or new input handling should be straightforward. All views must be notified when data changes.

38.  Solution: Decouple the data handling (Model), the data presentation (View) and the user input handling (Controller). Make each component a full-fledged object. The Model maintains a list of its Views (a View can subscribe/unsubscribe to a Model at run-time). Each View has an associated Controller. When the Model is modified it then notifies each View (this is known as the Notify/Subscribe pattern).

39. Sample Code class Model; class View { //Shown as an abstract base class protected:View();public: virtual void Update(Model *theChangedModel) = 0; };

40. class Model { //Concrete, but polymorphic private: List *_models; protected: Model(); public: void Subscribe(View *v) { _models->insert(v); } void Unsubscribe(View *v) { _models->remove(v); } virtual void Notify() { List ::iterator start, stop; start = _models->begin(); stop = _models->end(); for( ; start != stop; ++start) (*start).Update(this); } };

43. Examples  This is a basic pattern of user interface design.  The Smalltalk user-interface framework is based on the MVC pattern.  The Microsoft Foundation Class (MFC) library is also based on the MVC pattern.

44. Resulting Context  The Model has no specific knowledge of the possible Views.  The Model and View can belong to different levels of the system.  The View objects handle notification of changes in data in their own way (i.e., each View is a subclass of the abstract base class).

45. Rationale  This pattern supports multiple views for a model.  For example, data in a spreadsheet can be presented as a table or as a chart.  Different views for the model can be written without changing the model.  This kind of flexibility is a key to object- oriented programming.

46. Design Patterns  Design patterns describe subsystem structure.  Design patterns focus on particular design problems.  There are three categories of design patterns: creational, structural, and behavioral.