1 / 71

Chapter 3: Design Patterns

Chapter 3: Design Patterns. Feng Zhiyong Tianjin University March 12, 2006. Architectural Patterns. Design Patterns. programming language-specific idioms. Introduction.

nadda
Download Presentation

Chapter 3: 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. Chapter 3: Design Patterns Feng Zhiyong Tianjin University March 12, 2006

  2. Architectural Patterns Design Patterns programming language-specific idioms Introduction • Design patterns are medium-scale patterns. They are smaller in scale than architectural patterns, but are at a higher level than the programming language-specific idioms.

  3. Group Design Patterns • Structural Decomposition • Organization of Work • Access Control • Management • Communication

  4. Overview(1) • Structural Decomposition This category includes patterns that support a suitable decomposition of subsystems and complex components into cooperating parts. The Whole-Part pattern is the most general pattern we are aware of in this category. • Organization of Work. This category comprises patterns that define how components collaborate together to solve a complex problem. We describe the Master-Slave pattern, which helps you to organize the computation of services for which fault tolerance or computational accuracy is required.

  5. Overview(2) • Access Control. Such patterns guard and control access to services or components. We describe the Proxy pattern here. • Management. This category includes patterns for handling homogenous collections of objects, services and components in their entirety. We describe two patterns: the Command Processor pattern addresses the management and scheduling of user commands, while the View Handler pattern describes how to manage views in a software system.

  6. Overview(3) • Communication. Patterns in this category help to organize communication between components. Two patterns address issues of inter-process communication: the Forwarder-Receiver patterndeals with peer-to-peer communication, while the Client Dispatcher-Server pattern describes location-transparent communication in a Client-Server structure. The Publisher-Subscriber pattern helps with the task of keeping data consistent between cooperating components. *An important property of all design patterns is that they are independent of a particular application domain. *Most design patterns are independent of a particular programming paradigm.

  7. Structural Decomposition(1) • Structural Decomposition • Organization of Work • Access Control • Management • Communication

  8. Structural Decomposition() • The Whole-Part design pattern helps with the aggregation of components that together form a semantic unit. • The Composite pattern organizes objects into tree structures that represent part-whole hierarchies.

  9. The Whole-part Design Pattern • Example • Context • Problem • Solution • Structure • Dynamics • Implementation • Variants • Example Resolved • Known Uses • See also

  10. Whole-part-- Example

  11. Whole-part-- Context • Context Implementing aggregate objects.

  12. Whole-part-- Problem • A complex object should either be decomposed into smaller objects, or composed of existing objects, to support reusability, changeability and the recombination of the constituent objects in other types of aggregate. • Clients should see the aggregate object as an atomic object that does not allow any direct access to its constituent parts.

  13. Whole-part-- Solution Introduce a component that encapsulates smaller objects, and prevents clients from accessing these constituent parts directly. Define an interface for the aggregate that is the only means of access to the functionality of the encapsulated objects. allowing the aggregate to appear as a semantic unit. The general principle of the Whole-Part pattern is applicable to the organization of three types of relationship: • An assembly-parts relationship • A container-contents relationship • The collection-members relationship

  14. Whole-part—Structure(1)

  15. Whole-part—Structure(2)

  16. Whole-part—Dynamics(1)

  17. Whole-part—Dynamics(2)

  18. Whole-part– Implementation(1) 1 Design the public interface of the Whole. Analyze the functionality the Whole must offer to its clients. 2 Separate the Whole into Parts, or synthesize it from existing ones. There are two approaches: • The bottom-up approach allows you to compose Wholes from loosely-coupled Parts that you can later reuse when implementing other types of Whole. • The top-down approach makes it is possible to cover all of the Whole's functionality.

  19. Whole-part– Implementation(2) 3 If you follow a bottom-up approach,use existing Parts from component libraries or class libraries and specify their collaboration. 4 If you follow a top-down approach, partition the Mirhole's services into smaller collaborating services and map these collaborating services to separate Parts.

  20. Whole-part– Implementation(3) 5 Specify the services of the W'hole in terms of services of the Parts.---two possible ways to call a Part service: • If a client request is forwarded to a Part service, the Part does not use any knowledge about the execution context of the Whole, relying on its own environment instead. • A delegation approach requires the Whole to pass its own context information to the Part.

  21. Whole-part– Implementation(4) 6 Implement the Parts. If the Parts are Whole-Part structures themselves, design them recursively starting with step 1. If not, reuse existing Parts from a library, or just implement them if their implementation is straightforward and further decomposition is not necessary. 7 Implement the Whole. Implement the Whole's services based on the structure you developed in the preceding steps.

  22. Whole-part– Variants(1) Shared Parts.This variant relaxes the restriction that each Part must be associated with exactly one Whole by allowing several Wholes to share the same Part.

  23. Whole-part– Variants(2) The next three variants describe the implementation of the Whole-to-Parts relationships we introduced in the Solution section: • Assembly-Parts In this variant the Whole may be an object that represents an assembly of smaller objects. • Container-Contents. In this variant a container is responsible for maintaining differing contents. • The Collection-Members variant is a specialization of Container-Contents, in that the Part objects all have the same type.

  24. Whole-part– Example Resolved(1)

  25. Whole-part– Example Resolved(2)

  26. Whole-part– Example Resolved(3)

  27. Whole-part– Known Uses • The key abstractions of many object-oriented applications follow the Whole-Part pattern. • Most object-oriented class libraries provide collection classes such as lists. sets. and maps. These classes implement the Collection-Member and Container-Contents variants. • Graphical user interface toolkits such as Fresco or ET++ use the Composite variant of the Whole-Part pattern.

  28. Whole-part– Consequences Benefits: • Changeability of Parts • Separation of concerns • Reusability liabilities: • Lower eminency through indirection • Complexity of decomposition into Parts

  29. Whole-part– See also the Composite design pattern is applicable when: • You want to represent whole-part hierarchies of objects. • You want clients to be able to ignore the difference between compositions of objects and individual objects. • Composite is a variant of the Whole-Part design pattern that you should consider when facing these two requirements. • The Facade design pattern helps to provide a simple interface to a complex subsystem.

  30. 3.3 Organization of Work(1) • Structural Decomposition • Organization of Work • Access Control • Management • Communication

  31. Organization of Work(2) • The implementation of complex services is often solved by several components in cooperation. • The Master-Slave pattern supports fault computation and computational accuracy. • Master-Slave applies the 'divide and conquer' principle. • The Master-Slave pattern is widely applied in the areas of parallel and distributed computing. • The Chain of Responsibility, Command and Mediator patterns also belong to this category

  32. 3.3.1Master-Slave • Example • Context • Problem • Solution • Structure • Dynamics • Implementation • Variants • Known Uses • See also

  33. Master-Slave-- Example

  34. Master-Slave-- Context • Context Partitioning work into semantically-identical sub-tasks.

  35. Master-Slave– Problem(1) • Clients should not be aware that the calculation is based on the “divide and conquer” principle. • Neither clients nor the processing of sub-tasks should depend on the algorithms for partitioning work and assembling the final result.

  36. Master-Slave– Problem(2) • It can be helpful to use different but semantically-identical implementations for processing sub-tasks, for example to increase computational accuracy. • Processing of sub-tasks sometimes needs coordination, for example in simulation applications using the finite element method.

  37. Master-Slave-- Solution A master component divides work into equal sub-tasks, delegates these sub-tasks to several independent but semantically-identical shve components, and computes a final result from the partial results the slaves return. This general principle is found in three application areas: • Fault tolerance • Parallel computing • Computational accuracy

  38. Master-Slave—Structure(1)

  39. Master-Slave—Structure(2)

  40. Master-Slave—Dynamics(1) • A client requests a service from the master • The master partitions the task into several equal sub-tasks. • The master delegates the execution of these sub-tasks to several slave instances, starts their execution and waits for the results they return • The slaves perform the processing of the sub-tasks and return the results of their computation back to the master • The master computes a final result for the whole task from the partial results received from the slaves • The master returns this result to the client

  41. Master-Slave—Dynamics(2)

  42. Master-Slave– Implementation(1) The implementation of the Master-Slave pattern follows five steps: 1.Divide work. Specify how the computation of the task can be split into a set of equal sub-tasks. Identify the sub-services that are necessary to process a sub-task. 2.Combine sub-task results. Specify how the final result of the whole service can be computed with the help of the results obtained from processing individual sub-tasks.

  43. Master-Slave– Implementation(2) 3. Specify the cooperation between master and slaves. Define an interface for the sub-service identified in step 1. It will be implemented by the slave and used by the master to delegate the processing of individual sub-tasks. 4.Implement the slave components according to the specifications developed in the previous step. 5.Implement the master according to the specifications developed in step 1 to 3.

  44. Master-Slave– Variants(1) Master Slave for fault tolerance. In this variant the master just delegates the execution of a service to a fixed number of replicated implementations, each represented by a slave. Master-Slave for parallel computation. The master divides a complex task into a number of identical sub-tasks, each of which is executed in parallel by a separate slave. The master builds the final result from the results obtained from the slaves.

  45. Master-Slave– Variants(2) Master-Slave for computational accuracy. The execution of a service is delegated to at least three different implementations, each of which is a separate slave.

  46. Master-Slave– Variants(3) Further variants exist for implementing slaves: Slaves as Processes. To handle slaves located in separate processes, you can extend the original Master-Slave structure with two additional components Slaves as Threads.Every slave is implemented within its own thread of control. Master Slave with slave coordination.The computation of a slave may depend on the state of computation of other slaves

  47. Master-Slave– Known Uses • Matrix multiplication. Each row in the product matrix can be computed by a separate slave. • Transform-coding an image, for example in computing the discrete cosine transform (DCT) of every 8 x 8 pixel block in an image. Each block can be computed by a separate slave. • Computing the cross-correlation of two signals. This is done by iterating over all samples in the signal, computing the mean-square distance between the sample and its correlate, and summing the distances.

  48. Master-Slave– Consequences Benefits: • Exchangeability and extensibility • Separation of concerns • Efficiency liabilities: • Feasibility • Hard to implement • Portability

  49. Master-Slave– See also • The Master-Slave Pattern for Parallel Compute Services [Bro96] provides additional insights for implementing a Master-Slave structure. • The book Programming with Threads [KSS96] describes the Slaves as Threads variant in detail. • Object Group [Maf96] is a pattern for group communication and support of fault tolerance in distributed applications. It corresponds to the Master-Slave for fault tolerance variant and provides additional details for its implementation.

  50. 3.4 Access Control(1) • Structural Decomposition • Organization of Work • Access Control • Management • Communication

More Related