![Types of S/W Patterns design patterns (software design) [Buschmann-POSA] architectural (systems design)](https://image.slidesharecdn.com/softwarepatterns-091105120430-phpapp01/85/Software-Patterns-12-320.jpg)
![design (micro-architectures) [Gamma-GoF]](https://image.slidesharecdn.com/softwarepatterns-091105120430-phpapp01/85/Software-Patterns-13-320.jpg)
![idioms (low level) analysis patterns (recurring & reusable analysis models) [Flower]](https://image.slidesharecdn.com/softwarepatterns-091105120430-phpapp01/85/Software-Patterns-14-320.jpg)
Software Patterns
- 1. Software Patterns Sudarsun Santhiappan Director – Research & Development Burning Glass Technologies Chennai 600010
- 2. Coverage Object Oriented Thinking
- 7. Objectives Open a window to the architecture and design patterns world, explain why are they needed and where did they came from, and give some examples and real world tastes of chosen Design Pattern and Architectures
- 8. Not a programming language oriented lecture, we will mainly discuss the paradigms and uses with examples in various programming languages.
- 9. Programming Paradigms.. Block Programming
- 11. Object Oriented Programming Polymorphism + Late Binding (some) + Encapsulation (some) + Inheritance Component Oriented Polymorphism + Really Late Binding + Real, Enforced Encapsulation + Interface Inheritance + Binary Reuse SOA
- 12. Types of S/W Patterns design patterns (software design) [Buschmann-POSA] architectural (systems design)
- 13. design (micro-architectures) [Gamma-GoF]
- 14. idioms (low level) analysis patterns (recurring & reusable analysis models) [Flower]
- 15. organization patterns (structure of organizations/projects)
- 16. process patterns (software process design)
- 17. domain-specific patterns
- 18. Overview of the UML The UML is a language for visualizing
- 19. specifying
- 20. constructing
- 21. documenting the artifacts of a software-intensive system
- 22. Overview of the UML Modeling elements
- 23. Relationships
- 25. Diagrams
- 26. Modeling Elements Structural elements class, interface, collaboration, use case, active class, component, node Behavioral elements interaction, state machine Grouping elements package, subsystem Other elements note
- 28. Association
- 29. Generalization
- 30. Realization
- 32. Tagged value
- 33. Constraint
- 34. Models, Views, and Diagrams Activity Diagrams A model is a complete description of a system from a particular perspective Models Use Case Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Collaboration Diagrams State Diagrams State Diagrams Component Diagrams Component Diagrams Component Diagrams Deployment Diagrams State Diagrams State Diagrams Object Diagrams Scenario Diagrams Scenario Diagrams Statechart Diagrams Use Case Diagrams Use Case Diagrams Sequence Diagrams State Diagrams State Diagrams Class Diagrams
- 35. Diagrams A diagram is a view into a model Presented from the aspect of a particular stakeholder
- 36. Provides a partial representation of the system
- 37. Is semantically consistent with other views In the UML, there are nine standard diagrams Static views: use case, class, object, component, deployment
- 38. Dynamic views: sequence, collaboration, statechart, activity
- 39. Use Case Diagram Captures system functionality as seen by users
- 40. Use Case Diagram Captures system functionality as seen by users
- 41. Built in early stages of development
- 42. Purpose Specify the context of a system
- 43. Capture the requirements of a system
- 44. Validate a system’s architecture
- 45. Drive implementation and generate test cases Developed by analysts and domain experts
- 46. Class Diagram Captures the vocabulary of a system
- 47. Class Diagram Captures the vocabulary of a system
- 48. Built and refined throughout development
- 49. Purpose Name and model concepts in the system
- 51. Specify logical database schemas Developed by analysts, designers, and implementers
- 52. Object Diagram Captures instances and links
- 53. Object Diagram Shows instances and links
- 54. Built during analysis and design
- 55. Purpose Illustrate data/object structures
- 56. Specify snapshots Developed by analysts, designers, and implementers
- 57. Component Diagram Captures the physical structure of the implementation
- 58. Component Diagram Captures the physical structure of the implementation
- 59. Built as part of architectural specification
- 60. Purpose Organize source code
- 61. Construct an executable release
- 62. Specify a physical database Developed by architects and programmers
- 63. Deployment Diagram Captures the topology of a system’s hardware
- 64. Deployment Diagram Captures the topology of a system’s hardware
- 65. Built as part of architectural specification
- 66. Purpose Specify the distribution of components
- 67. Identify performance bottlenecks Developed by architects, networking engineers, and system engineers
- 68. Sequence Diagram Captures dynamic behavior (time-oriented)
- 69. Sequence Diagram Captures dynamic behavior (time-oriented)
- 70. Purpose Model flow of control
- 72. Collaboration Diagram Captures dynamic behavior (message-oriented)
- 73. Collaboration Diagram Captures dynamic behavior (message-oriented)
- 74. Purpose Model flow of control
- 75. Illustrate coordination of object structure and control
- 76. Statechart Diagram Captures dynamic behavior (event-oriented)
- 77. Statechart Diagram Captures dynamic behavior (event-oriented)
- 78. Purpose Model object lifecycle
- 79. Model reactive objects (user interfaces, devices, etc.)
- 80. Activity Diagram Captures dynamic behavior (activity-oriented)
- 81. Activity Diagram Captures dynamic behavior (activity-oriented)
- 82. Purpose Model business workflows
- 83. Model operations
- 84. Architecture and the UML Design View Implementation View Process View Deployment View Organization Package, subsystem Dynamics Interaction State machine Components Classes, interfaces, collaborations Active classes Nodes Use Case View Use cases
- 85. Software engineering process A set of partially ordered steps intended to reach a goal. In software engineering the goal is to build a software product or to enhance an existing one . Architectural process Sequence of activities that lead to the production of architectural artifacts: A software architecture description
- 87. System Architecture Logical View Implementation View Programmers Software management Process View Deployment View System topology Delivery, installation Communication System engineering Conceptual Physical Use Case View Conceptual Physical End-user Functionality Performance Scalability Throughput System integrators
- 88. Pattern Oriented Software Architecture Patterns for Software Architecture, Distributed Systems and Resource Management Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal. Pattern-oriented Software Architecture: System of Patterns Vol 1. John Wiley and Sons Ltd. 1996.
- 89. Frank Buschmann, Douglas Schmidt, Michael Stal, Hans Rohnert. Pattern-oriented Software Architecture Vol 2: Patterns for Concurrent and Networked Objects. John Wiley and Sons Ltd. 2000.
- 90. Michael Kircher, Prashant Jain. Pattern-Oriented Software Architecture: Patterns for Distributed Services and Components. John Wiley and Sons Ltd. 2004. Three types of patterns (Buschmann et al.): Architectural Patterns An architectural pattern expresses a fundamental structural organization for software systems or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. Design Patterns A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes commonly recurring structure of communicating components that solve a design problem within a particular context. Idioms An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.
- 91. Architecture - Definition Highest level representation of a system
- 92. How a big system could be broken down into smaller components ?
- 93. Shared understanding of a system
- 94. How major components fit together ?
- 95. How components interact ?
- 96. Example: Nokia MITA Mobile Internet Technical Architecture Intranet (WLAN)/Bluetooth Web domain Internet xDSL PSTN Mobile networks GSM EDGE WCDMA Mobile domain WLAN /Bluetooth Bluetooth =Server
- 97. Architecture Software architecture encompasses the set of significant decisions about the organization of a software system selection of the structural elements and their interfaces by which a system is composed
- 98. behavior as specified in collaborations among those elements
- 99. Composition of these structural and behavioral elements into larger subsystem
- 100. architectural style that guides this organization
- 102. functionality
- 103. performance
- 104. resilience
- 105. reuse
- 106. comprehensibility
- 107. economic and technology constraints and trade offs
- 108. aesthetic concerns
- 109. Who are the architects? Experience software development
- 110. domain Pro-active, goal oriented
- 113. Architect Not just a top level designer Need to ensure feasibility Not the project manager But “joined at the hip” Not a technology expert Purpose of the system, “fit”, Not a lone scientist Communicator
- 114. Software Architecture Team Charter Defining the architecture of the software
- 115. Maintaining the architectural integrity of the software
- 116. Assessing technical risks related to the software design
- 117. Proposing the order and contents of the successive iterations
- 118. Consulting services
- 119. Assisting marketing for future product definition
- 120. Facilitating communications between project teams
- 121. Architecture is making decisions The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.
- 122. Architectural design Identify, select, and validate “architecturally significant” elements
- 123. Not everything is architecture Main “business” classes
- 124. Important mechanisms
- 127. Interfaces Produce a Software Architecture Documen
- 128. Architectural design workflow Select scenarios: criticality and risk
- 129. Identify main classes and their responsibility
- 130. Distribute behavio r on classes
- 131. Structure in subsystems, layers, define interfaces
- 132. Define distribution and concurrency
- 134. Derive tests from use cases
- 135. Evaluate architecture Iterate Use case view Logical view Deployment view Implementation view Process view
- 136. Patterns A pattern is a solution to a problem in a context
- 137. A pattern codifies specific knowledge collected from experience in a domain
- 138. All well-structured systems are full of patterns Idioms
- 139. Design patterns
- 141. Patterns - Definition 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 .
- 142. Each pattern is a three-part rule , which expresses a relation between a certain context , a problem , and a solution .
- 143. GoF: The design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context
- 144. Why Patterns? Patterns can be used by programmers, designers, and architects who are building applications and who want to improve either their understanding of architectural issues or their communication about them. (Fowler)
- 145. Patterns are common solutions to recurring problems. If you have worked in applications for a while, you may well know most of them. They are industry’s old ideas . If you are new , pattern book can help you learn about those techniques. If you are familiar with the techniques, pattern book can help you communicate and teach them to others. An important part of patterns is trying to build a common vocabulary for communication . (Fowler)
- 146. Patterns constitute an effort to build on the collective experience of skilled designers and software engineers. (Buschmann et al.)
- 147. Experts already have solutions to many recurring design problems . (Buschmann et al.)
- 148. Patterns capture proven solutions in an easily-available and, hopefully, well-written form (Buschmann et al.)
- 149. Patterns support both novices and experts in software development. (Buschmann et al.)
- 151. Architectural patterns Distributed Layered
- 152. Event-driven MVC
- 153. Frame-based IR-centric
- 154. Batch Subsumption
- 155. Pipes and filters Disposable
- 156. Repository-centric
- 157. Blackboard
- 158. Interpreter
- 159. Rule-based
- 160. Model View Controller The Model-View-Controller (MVC) pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes
- 161. The controller changes the model
- 162. The View Listens to Model
- 163. Process Control!
- 164. What is the Layers Pattern? Architectural pattern that helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.
- 165. What is high? What is low?
- 166. Flow requests from higher layer to lower layer
- 167. answers from lower layer to higher layer
- 168. incoming data or event notification from low to high
- 169. Things to Take Care of... Late source code changes should not ripple
- 170. Interfaces should be stable
- 171. Interfaces may be prescribed by a standards body
- 172. Parts of the system should be exchangeable
- 173. Design for change!
- 174. May be necessary to build other systems at a later date with same low-level issues
- 175. Similar responsibilities should be grouped to help understandability and maintainability
- 176. No standard component granularity
- 177. Complex components may need further decomposition
- 178. More... Crossing component boundaries may impede performance substantial amount of data transferred over several boundaries The system will be built by actual human beings Work must be subdivided along clear boundaries
- 179. Architecture influences team structure and vice versa
- 180. Solution Structure the system into an appropriate number of layers
- 181. Think of lowest level as Layer 1; highest Layer N
- 182. This gives a conceptual view – not marching orders regarding sequence of further design
- 183. Within a layer, all subcomponents work at the same level of abstraction
- 184. Most of what Layer J provides is composed of services provided by Layer J-1, combined in a meaningful way for the application.
- 185. Illustration
- 186. Implementation Define which of the abstraction criteria you will use
- 187. Determine the number of abstraction levels according to your criterion
- 188. Name the layers and assign tasks to each of them
- 189. Specify the services
- 190. Refine the layering repeat steps 1-4 until natural, stable layering evolves
- 191. Finding layers is not orderly – yo-yo development Specify an interface for each layer
- 192. Implementation Structure individual layers
- 193. Specify communication between adjacent layers push/pull Decouple adjacent layers t op-down: J+1 knows about J; J can ignore J+1
- 194. bottom-up: can use callbacks
- 195. can decouple the upper from the lower somewhat Design an error-handling strategy
- 196. Some Applications Virtual Machines
- 197. APIs
- 198. Information Systems – Lower Layer is DB Presentation
- 199. Application Logic
- 200. Domain Layer
- 202. SOA SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents.
- 203. A service is a unit of work done by a service provider to achieve desired end results for a service consumer
- 204. in SOA, services are the mechanism by which needs and capabilities are brought together.
- 205. SOA - Principles Visibility – the ability for a service consumer to “see” a service provider (Awareness, willingness and Reachability)
- 206. Interaction - the activity of using a capability. (usually message exchange - by contracts, constraints and policies, for example Web Service Description Language)
- 207. Effect – the result of an interaction
- 208. SOAP: Simple Object Access Protocol
- 209. WSDL: Web Service Description Language
- 210. SOA - example
- 211. Idioms
- 212. Guard Problem Want to tie key scoped behaviors to actual program scopes e.g., program trace, resource acquisition/release, locking However, tying functions to functions is error-prone e.g., forgetting the release call, exceptional return paths Solution Design a special adapter class whose constructor and destructor call the key scope entry and exit behaviors
- 213. Create a guard object on the program call stack (in a scope) Context limitations Mainly limited to languages with constructor/destructor
- 214. Design Patterns
- 215. What are design patterns? The Beginning - “Gang of four” (Gama et al 1995) What's the difference between an architecture and a Design patterns?
- 216. Patterns sub types: Creational
- 217. Structural
- 218. Behavioral
- 220. Template Method Pattern Intent / Applicability Intent Define the skeleton of an algorithm, deferring some steps to subclasses.
- 221. Template Method lets subclasses redefine certain steps of an algorithm, without changing the algorithm’s structure. Applicability – Use Template Method Pattern… To implement the invariant part of an algorithm, and leave it up to subclasses to implement the part that can vary.
- 222. When common code in subclasses should be factored and localized in a common base class to avoid code duplication.
- 223. To control extensions to subclasses. (Hook operations)
- 224. Template Method Pattern Participants AbstractClass Defines abstract primitive operations that concrete subclasses define to implement steps of an algorithm.
- 225. Implements a template method defining the skeleton of an algorithm. It calls primitive operations as well as other operations in the AbstractClass (or other classes). ConcreteClass Implements primitive operations to carry out subclass-specific steps of the algorithm. Note: Some concrete AbstractClass methods can also be defined. Hollywood Principle – “Don’t call us, we’ll call you.” => Parent class calls operations of subclass.
- 226. Strategy Pattern Intent / Applicability Intent Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Applicability – Use Strategy Pattern when… Many related classes differ only in their behavior.
- 227. You need different variants of an algorithm. For example, defining different algorithms based on space-time tradeoffs.
- 228. An algorithm uses data that a client shouldn’t know about.
- 229. A class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead, move related conditional branches into their own Strategy class.
- 230. Strategy Pattern - Participants Strategy Declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy. ConcreteStrategy Implements the algorithm using the Strategy interface. Context Is configured with a ConcreteStrategy object
- 231. Maintains a reference to a Strategy object
- 232. May define an interface that lets Strategy access its data.
- 233. Strategy Pattern - Participants http://www.dofactory.com/Patterns/PatternStrategy.aspx Show code in RealWorld Example Strategy SortStrategy ConcreteStrategy QuickSort
- 234. ShellSort
- 235. MergeSort Context SortedList Picture & Example from: http:// www.dofactory.com/Patterns/PatternStrategy.aspx
- 236. Strategy – Consequences Good Consequences Good for families of related algorithms. Inheritance can help factor out common functionality of algorithms.
- 237. Alternative to subclassing which allows the developer to vary the algorithm independent of its context.
- 238. Strategies eliminate conditional statements.
- 239. Provide different implementations of the same behavior. Example: Sorting is goal, but many ways to sort. Drawbacks Clients must be aware of different strategies.
- 240. Communication overhead between Strategy and Context – some concrete strategies may not need all the parameters passed into them.
- 241. Increased number of objects. See Flyweight pattern for an approach to solve this.
- 242. Iterator Intent Provide a means to Iterate through a series of nodes in specific way(s) Motivation To traverse lists of information without having to know anything too specific about the objects
- 243. To implement multiple algorithms to traverse those nodes.
- 244. Class Diagram
- 245. Iterator:Implementation Who Controls the Iteration? External Iterator Client controls iteration
- 246. Client must explicitly request next() on each node Internal Iterator Iterator controls iteration
- 247. Client hands an operation to the Iterator, Iterator tells every child in the aggregate to perform it.
- 248. Implementation Benefits External Iterator More flexible than Internal. Can compare 2 collections easily Internal Iterator Easier to use, as they define the iteration logic for you. Makes portability easier.
- 249. Who defines the traversal Algorithm? Algorithm can be held by a class outside of the Iterator. It could be held by the aggregate can hold it. Called “the cursor.”
- 250. Allows the algorithm to access private members of the aggregate (and not break encapsulation) Algorithm is held by the iterator Allows algorithms to be swapped out easily.
- 251. How Robust is the Iterator? If an iterator is robust it Will allow for removal of nodes in the middle of traversal.
- 252. It does this through registering the iterator with the aggregate. If any nodes are removed, it is notified.
- 253. Additional Iterator Operations All come with first, next, isdone, and currentItem
- 254. Previous Goes to the previous node that was iterated
- 255. Can be helpful in certain situations SkipTo Skips to a certain node.
- 256. Goes to a node matching specific criteria
- 257. Observer Pattern Behavioral Pattern
- 258. one-to-many dependency model, so that when one object changes state, all its dependents are notified and updated automatically without coupling the notifying object to the objects that are notified. Example: Button expose a clicked event that encapsulate click state, thus publish himself as an observable. Clients that are interested in this event register to it, thus becomes observers.
- 259. Observer and observable are bonded in a contract and can be completely loosely coupled from one another.
- 260. Singleton design pattern Creational pattern
- 261. ensure that a class has only one instance, and to provide a global point of access to it Example: Class SomeClass { static SomeClass singleTonInstance = null; static SomeClass GetInstance() { if(singleTonInstance == null) singleTonInstance = new SomeClass() return singleTonInstance; } }
- 262. Factory design patterns (Abstract \ Lightweight) Creational pattern
- 263. Can be given to client (abstract), pass construction parameters or read creation types from configuration or system environment
- 264. Can use object pool (Lightweight)
- 265. Factory design pattern - example abstract class GUIFactory { public static GUIFactory getFactory() { int sys = readFromConfigFile("OS_TYPE"); return sys == 0 ? new WinFactory() : new OSXFactory(); } public abstract Button createButton(); } class WinFactory:GUIFactory { public override Button createButton() { return new WinButton(); } } class MacFactory:GUIFactory { public override Button createButton(){ return new MacButton(); } } abstract class Button { public string caption; public abstract void paint(); }
- 266. class WinButton:Button { public override void paint() { // paint a button with Win API…} } class MacButton:Button { public override void paint() { // paint a button Mac style… } } class Application { static void Main(string[] args) { GUIFactory aFactory = GUIFactory.getFactory(); Button aButton = aFactory.createButton(); aButton.caption = "Play"; aButton.paint(); } } Factory design pattern - example
- 267. Façade design pattern Structural Pattern
- 268. Provide a unified interface to a set of interfaces in a subsystem without damaging the genric form of the sub system.
- 269. Decorator pattern Structural Pattern
- 270. Avoid excessive sub-classing and gain run time flexibility
- 271. Example: Java.IO package BufferedReader br = new BufferedReader( new InputStreamReader( new FileInputStream(inFile))); All derives from abstract io.Reader
- 272. Example
- 273. Example // the Window interface interface Window { public void draw(); // draws the Window public String getDescription(); // returns a description of the Window } // implementation of a simple Window without any scrollbars class SimpleWindow implements Window { public void draw() { // draw window } public String getDescription() { return "simple window"; } } // abstract decorator class - note that it implements Window abstract class WindowDecorator implements Window { protected Window decoratedWindow; // the Window being decorated public WindowDecorator (Window decoratedWindow) { this.decoratedWindow = decoratedWindow; } }
- 274. Example // the first concrete decorator which adds vertical scrollbar functionality class VerticalScrollBarDecorator extends WindowDecorator { public VerticalScrollBarDecorator (Window decoratedWindow) { super(decoratedWindow); } public void draw() { drawVerticalScrollBar(); decoratedWindow.draw(); } private void drawVerticalScrollBar() { // draw the vertical scrollbar } public String getDescription() { return decoratedWindow.getDescription() + ", including vertical scrollbars"; } } // the second concrete decorator which adds horizontal scrollbar functionality class HorizontalScrollBarDecorator extends WindowDecorator { public HorizontalScrollBarDecorator (Window decoratedWindow) { super(decoratedWindow); } public void draw() { drawHorizontalScrollBar(); decoratedWindow.draw(); } private void drawHorizontalScrollBar() { // draw the horizontal scrollbar } public String getDescription() { return decoratedWindow.getDescription() + ", including horizontal scrollbars"; } }
- 275. Example public class DecoratedWindowTest { public static void main(String[] args) { // create a decorated Window with // horizontal and vertical scrollbars Window decoratedWindow = new HorizontalScrollBarDecorator ( new VerticalScrollBarDecorator( new SimpleWindow())); // print the Window's description System.out.println(decoratedWindow.getDescription()); } } Output: "simple window, including vertical scrollbars, including horizontal scrollbars"
- 276. Strategy Pattern Behavioral Pattern
- 277. defines a family of interchangeable encapsulated algorithms that receives the same input type and provides the same output type in different manners that can be determined in run-time. static void Main( { SortedList studentRecords = new SortedList(); studentRecords.Add("Samual"); studentRecords.Add("Jimmy"); studentRecords.Add("Sandra"); studentRecords.SetSortStrategy(new QuickSort()); studentRecords.Sort(); studentRecords.SetSortStrategy(new ShellSort()); studentRecords.Sort(); }
- 278. Strategy Pattern - example abstract class SortStrategy { public abstract void Sort(ArrayList list) } class QuickSort : SortStrategy { public override void Sort(ArrayList list) { list.Sort(); // Default is Quicksort } } class ShellSort : SortStrategy { public override void Sort(ArrayList list) { //list.ShellSort(); not-implemented } }
- 279. class SortedList { private ArrayList list = new ArrayList(); private SortStrategy sortstrategy; public void SetSortStrategy(SortStrategy sortstrategy) { this.sortstrategy = sortstrategy; } public void Add(string name) { list.Add(name); } public void Sort() { sortstrategy.Sort(list); } } Strategy Pattern - example
- 280. Proxy Pattern Intent Provide a surrogate or placeholder for another object to control access to it Other Names Surrogate
- 281. Proxy Pattern: Applicability Forms of the proxy pattern: Remote proxy – Provides a local representative for an object in a different address space.
- 282. Virtual Proxy – Creates expensive objects on demand.
- 283. Protection Proxy – Controls access to the original object.
- 284. Smart References – Additional functionality pointers. Smart Pointers
- 285. Initial loading of persistent objects.
- 286. Object locking.
- 287. Proxy Pattern: Participants Proxy Maintains a reference to the real subject.
- 288. Provide identical interface to Subject so the Proxy can be substituted.
- 289. Controls access to the real subject and may be responsible for creating and deleting the real subject. RealSubject Defines the real object that the proxy represents. Subject Defines the common interface for RealSubject and Proxy so that the proxy to be used wherever a RealSubject is expected.
- 291. Proxy Pattern: Example class Image; class ImagePtr { public: ImagePtr(const char* file); virtual ~ImagePtr(); virtual Image* operator->(); virtual Image& operator*(); private: Image* _image; const char* _file; Image* LoadImage(); }; Image* ImagePtr::LoadImage(){ If (_image == 0 ) { _image = LoadAnImageFile(_file); } return _image; } Image* ImagePtr::operator->() { return LoadImage(); } Image& ImagePtr::operator*(){ return *LoadImage(); } To implement the Real Subject methods: ImagePtr image = ImagePtr(“aFile”); image->Draw(Point(50,100)); //(image.operator->())->Draw(Point(50,100))
- 292. Proxy Pattern: Consequences Each proxy introduces a level of indirection. This may result in hiding detail from the implementer. A remote Proxy can hide the fact that object resides in a different address space.
- 293. A Virtual Proxy can perform optimizations such as creation on demand.
- 294. Protection Proxy and Smart References can allow additional housekeeping tasks when object is accessed. Copy-On-Write This hides optimization in which an object is not copied until it’s attributes are modified.
- 295. Proxy: Related Patterns Adapter Provides a different interface to an object. Since a proxy may deny request based on access, the interface is will be a subset. Decorator Similar implementation to proxy but has a different purpose. This adds responsibilities to an object rather than controlling access.
- 296. Adapter Pattern a.k.a. Wrapper
- 297. Has both class and object forms
- 298. Adapts the interface of one class into that of an otherwise incompatible class
- 299. Use to: make use of a class with incompatible interface
- 300. create reusable class that will play nice with others
- 301. use several subclasses without having to subclass each one to adapt their interface (object form)
- 303. Adapter Pattern Participants Target defines the domain-specific interface that Client uses Client collaborates with objects conforming to Target interface Adaptee defines existing interface that needs adapting Adapter adapts the interface of Adaptee to the Target interface Collaborations Clients call operations on Adapter instance, which in turn calls the appropriate Adaptee operations
- 304. Adapter Pattern Consequences Class form commits to a concrete Adaptee class, so won’t work if we want to adapt a class as well as subclasses (use object form)
- 305. Adapter can override Adaptee’s behavior
- 306. introduces only one object; no pointer indirection required Object form allows single Adapter to work with many Adaptee subclasses; can add functionality to all Adaptees at once
- 307. harder to override Adaptee behvarior – have to subclass Adaptee and make Adapter refer to the subclass
- 308. Adapter Pattern Other Issues How much work does Adapter do? simple: changing names of otherwise identical operations
- 309. complex: supporting new functionality Pluggable Adapters use interface adaptation to make class more reusable Two-way Adapters a class adapter conforms to both incompatible classes
- 311. Adapter Pattern Implementation Issues Class adapters in C++ adapts publicly from Target and privately from Adaptee
- 312. Adapter is subtype of Target, not Adaptee Pluggable Adapters Find “narrow” interface – smallest subset of operations
- 313. Either: make operations abstract in Target for different Adapters to implement
- 314. put operations in abstract delegate class for different Adapters to subclass
- 315. Adapter Pattern Related Patterns Bridge – similar structure, but meant to separate interface from its implementation, rather than change interface of existing object
- 316. Decorator – enhances object without changing its interface. Thus more transparent and supports recursive composition
- 317. Proxy – defines surrogate for another object without changing its interface
- 318. Bridge Pattern a.k.a. Handle/Body
- 319. Decouples abstraction from its implementation
- 320. Use to: avoid binding abstraction to implementation (i.e. want to choose different implementations at runtime)
- 321. make both abstraction and implementations independently extensible
- 322. change implementation or abstraction without impacting clients, or hide them from clients
- 323. share implementation among clients without letting them know
- 325. Bridge Pattern Participants Abstraction defines abstraction’s interface
- 326. maintains reference to Implementor instance RefinedAbstraction extends interface defined by Abstraction Implementor defines interface for implementation classes
- 327. typically provides more primitive operations than Abstraction ConcreteImplementor implements Implementor interface Collaborations Abstraction forwards client requests to its Implementor object
- 328. Bridge Pattern Consequences decouples interface and implementation allows selecting implementation at runtime
- 329. avoids compilation dependencies on implementation improves extensibility Abstraction and Implementation can be extended independently hides implementation details from clients
- 330. Bridge Pattern Implementation Issues for only one implementation, may not need abstract Implementor
- 331. how, where, and when to choose concrete Implementor? by Abstraction, in its constructor?
- 332. change at runtime?
- 333. by another object, like an Abstract Factory? sharing Implementors Handle/Body idiom multiple inheritance combines interface back with implementation
- 334. Bridge Pattern Related Patterns Abstract Factory can create and configure Bridges
- 335. Adapter makes existing unrelated classes work together; whereas Bridge is used in design in effort to avoid needing Adapters later
- 337. This design pattern coordinates the concurrent production and consumption of information among producer and consumer objects that are working on different threads.
- 338. This pattern is used with some type of semaphore
- 339. Consumer/Producer - example static AutoResetEvent eventProducerDone = new AutoResetEvent(false); static AutoResetEvent eventConsumerDone = new AutoResetEvent(false); static int currentNum = 0; static void produce(object stateInfo) { eventProducerDone.Set(); while (true) { //wait for the consumer eventConsumerDone.WaitOne(); currentNum++; eventProducerDone.Set(); } }
- 340. static void Main(string[] args) { ThreadPool.QueueUserWorkItem(new WaitCallback(produce)); for (int i = 0; i < 20; i++) { eventProducerDone.WaitOne(); System.Diagnostics.Debug.WriteLine(currentNum); eventConsumerDone.Set(); } } Consumer/Producer - example
- 341. Top 10 Misconceptions (1) A pattern is a solution to a problem in a context.
- 342. Why isn’t this true? Patterns are applied to recurring problems (not one instance).
- 343. Patterns teach , so that the developer can tailor the solution to a variant of the problem.
- 344. Patterns have a name .
- 345. Top 10 Misconceptions (2) Patterns are just jargon, rules, programming tricks, data structures, etc. The idea of patterns is old… experienced programmers used previous solutions on new problems.
- 346. What is new is naming them and writing them down.
- 347. One drawback (from personal experience) is to assume everyone knows the pattern. Design documentation should note the name of the design pattern used, but that shouldn’t be the extent of the documentation.
- 348. Top 10 Misconceptions (3) Seen one, seen them all. Patterns are extremely diverse.
- 349. Don’t make assumptions about all patterns based on a few patterns.
- 350. Top 10 Misconceptions (4) Patterns need tool or methodological support to be effective. Benefits of patterns (no tool or support needed!) Patterns capture expertise and make it accessible to non-experts.
- 351. Pattern names form a vocabulary which helps developers communicate.
- 352. Documenting the design with the patterns in use helps people understand the system more quickly.
- 353. Patterns facilitate restructuring a system whether or not it was designed with patterns in mind.
- 354. Top 10 Misconceptions (5) Patterns guarantee reusable software, higher productivity, world peace, etc. Patterns don’t guarantee anything.
- 355. Similar comments were made about object-oriented programming when it was introduced. (6) Patterns ‘generate’ whole architectures. Need human creativity to know how to apply and tailor a pattern for your given problem.
- 356. Need to fill in the “white space” between the patterns.
- 357. Through teaching / discussion, patterns may support “generativity” – helping the reader solve problems that the pattern doesn’t address explicitly.
- 358. Top 10 Misconceptions (7) Patterns are for (object-oriented) design or implementation. Patterns capture expertise, but are not limited to design and implementation.
- 359. Patterns can be found in analysis, maintenance, testing, documentation, organizational structure, etc.
- 360. Top 10 Misconceptions (8) There’s no evidence that patterns help anybody. Improve teaching and communication. (9) The pattern community is a clique of elites. Attendees of Pattern Languages of Programming (PLoP) conferences included analysts, designers, implementors, students, professionals, authors, even a non-computer scientist. (10) The pattern community is self-serving, even conspiratorial. Common desire of leading pattern authors is to impart expertise, best practices, and competitive advantage to others.
Editor's Notes
- #52: Low hardware traps sensor input reading electrical signals from a wire High user-visible functionality high-level policies such as phone tariffs