Difference between revisions of "DesignPatterns"
From Suhrid.net Wiki
Jump to navigationJump to search (→Facade) |
|||
Line 24: | Line 24: | ||
== Consequences == | == Consequences == | ||
* Shield clients from myriad subsystem components - hence promote weak coupling between clients and subsystems. | * Shield clients from myriad subsystem components - hence promote weak coupling between clients and subsystems. | ||
− | * | + | * Reduces number of objects clients have to deal with. |
[[Category:OODE]] | [[Category:OODE]] |
Revision as of 09:02, 17 December 2011
Intro
- A design pattern systematically names, explains, and evaluates an important and recurring design problem and its solution.
- They capture the intent behind a design by identifying objects, collaborations, and distributions of responsibilities.
- They capture static and dynamic structures of successful solutions to problems.
- Patterns support reuse of software architecture and design.
- They give software engineers a vocabulary with which to describe their designs.
- Patterns solve design problems such as:
- Finding appropriate classes to solve a problem.
- Determining how abstract or how concrete a class should be.
- Specifying interfaces of classes, architectures, and binary components.
- Designing for change.
- Patterns are not code-reuse they are experience reuse !
Facade
Intent
- Provide a common interface to a set of interfaces within a subsystem.
- Defines a higher level interface to make the subsystem interfaces easier to use.
Motivation
- Provide a simplified interface.
Consequences
- Shield clients from myriad subsystem components - hence promote weak coupling between clients and subsystems.
- Reduces number of objects clients have to deal with.