CSC/ECE 517 Fall 2012/ch2b 2w42 aa: Difference between revisions
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
==Facade Pattern== | ==Facade Pattern== | ||
Intent<br> | |||
1) Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.<br> | |||
2) Wrap a complicated subsystem with a simpler interface.<br> | |||
Problem<br> | |||
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem.<br> | |||
Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object.<br> | |||
==Abstract Factory Pattern== | ==Abstract Factory Pattern== | ||
Intent<br> | |||
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes.<br> | |||
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”.<br> | |||
3) The new operator considered harmful.<br> | |||
Problem<br> | |||
If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code.<br> | |||
Discussion<br> | |||
Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them. | |||
This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton.<br> | |||
==Mediator Pattern== | ==Mediator Pattern== | ||
Revision as of 01:40, 19 November 2012
Introduction
Facade Pattern
Intent
1) Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
2) Wrap a complicated subsystem with a simpler interface.
Problem
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem.
Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object.
Abstract Factory Pattern
Intent
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”.
3) The new operator considered harmful.
Problem
If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code.
Discussion
Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.
This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton.