Http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE 517 Fall 2011/ch4 4h kp: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
This page has been moved to [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4h_kp http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4h_kp] | This page has been moved to [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4h_kp http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4h_kp] | ||
==Design Patterns at a Glance== | |||
{| class="wikitable" border="1" | |||
|- | |||
! Design Patterns | |||
! Singleton | |||
! Adapter | |||
! Command | |||
! Strategy | |||
|- | |||
! Purpose | |||
| To ensure a class has only one instance, and also to provide a global point of access to it | |||
| To convert the interface of a class into another interface the clients expects | |||
| To encapsulate method invocations so as to decouple caller from the implementation details | |||
| To perform a bunch of different things to do, based on the situation/context | |||
|- | |||
! Advantages | |||
| Sane usage of global namespace by avoiding unnecessary global variables and providing on-demand (lazy) instantiations. | |||
| It lets classes work together that could not otherwise because of incompatible interfaces. | |||
| It allows one to decouple the requester of an action from the object that actually performs the action. | |||
| It lets the algorithms vary independently from clients that use those. | |||
|- | |||
! Disadvantages | |||
| Introduces global state into system and complicates unit testing. | |||
| Adapter has to implement the entire target interface. Selective functionality implementation is not an option. | |||
| Having Command objects specific to each action ends up cluttering the design, especially in the context of MVC architectures <ref>[http://www.codeproject.com/KB/architecture/commandpatterndemo.aspx]</ref> | |||
| Increases the number of objects and all algorithms use the same interface. <ref> [www.cs.toronto.edu/~arnold/407/.../stateStrategy/state_strat_pres.ppt] </ref> | |||
|} |
Revision as of 19:34, 21 October 2011
This page has been moved to http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4h_kp
Design Patterns at a Glance
Design Patterns | Singleton | Adapter | Command | Strategy |
---|---|---|---|---|
Purpose | To ensure a class has only one instance, and also to provide a global point of access to it | To convert the interface of a class into another interface the clients expects | To encapsulate method invocations so as to decouple caller from the implementation details | To perform a bunch of different things to do, based on the situation/context |
Advantages | Sane usage of global namespace by avoiding unnecessary global variables and providing on-demand (lazy) instantiations. | It lets classes work together that could not otherwise because of incompatible interfaces. | It allows one to decouple the requester of an action from the object that actually performs the action. | It lets the algorithms vary independently from clients that use those. |
Disadvantages | Introduces global state into system and complicates unit testing. | Adapter has to implement the entire target interface. Selective functionality implementation is not an option. | Having Command objects specific to each action ends up cluttering the design, especially in the context of MVC architectures <ref>[1]</ref> | Increases the number of objects and all algorithms use the same interface. <ref> [www.cs.toronto.edu/~arnold/407/.../stateStrategy/state_strat_pres.ppt] </ref> |