CSC/ECE 517 Fall 2009/wiki2 13 StaticDynamic - Revision history

Kanke: /* Lazy Initialization Pattern */

2009-10-12T22:53:47Z

Lazy Initialization Pattern

← Older revision		Revision as of 22:53, 12 October 2009
Line 122:		Line 122:
	* Lazy Factory method, gets the instance associated with a		* Lazy Factory method, gets the instance associated with a
	* certain type. Instantiates new ones as needed.		* certain type. Instantiates new ones as needed.
	* precondition: type. Any string that describes a type
	* postcondition: The instance associated with that type.
	*/		*/
	Pizza* Pizza::getPizza(const string& type) {		Pizza* Pizza::getPizza(const string& type) {

Kanke: /* Lazy Initialization Pattern */

2009-10-12T22:53:09Z

Lazy Initialization Pattern

← Older revision		Revision as of 22:53, 12 October 2009
Line 94:		Line 94:
	=== Where dynamically typed language is more concise ===		=== Where dynamically typed language is more concise ===
	====Lazy Initialization Pattern====		====Lazy Initialization Pattern====
	Here is an example of Lazy Initialization Pattern for a Pizza class in C++:		Here is an example of Lazy Initialization Pattern for a Pizza class in C++ (From [http://en.wikipedia.org/wiki/Lazy_initialization Lazy initialization Wiki] with minor modifications):

	<pre>		<pre>

Kanke: /* Design Pattern */

2009-10-12T22:49:21Z

Design Pattern

← Older revision		Revision as of 22:49, 12 October 2009
Line 58:		Line 58:
	\| State \|\| Alter an object's behavior like change its class when its internal state changes. \|\| [http://en.wikipedia.org/wiki/State_pattern]		\| State \|\| Alter an object's behavior like change its class when its internal state changes. \|\| [http://en.wikipedia.org/wiki/State_pattern]
	\|-		\|-
	\| Strategy \|\| Encapsulates ~~an algorithm~~ inside a class \|\| [http://en.wikipedia.org/wiki/Strategy_pattern]		\| Strategy \|\| Encapsulates a family of algorithms inside a class so they can vary independently from the client using them. \|\| [http://en.wikipedia.org/wiki/Strategy_pattern]
	\|-		\|-
	\| Template Method \|\| ~~Defer~~ the ~~exact~~ steps ~~of an~~ algorithm ~~to a subclass~~ \|\| [http://en.wikipedia.org/wiki/Template_pattern]		\| Template Method \|\| Allow the subclass to redefine the detailed steps without modifying algorithm's structure. \|\| [http://en.wikipedia.org/wiki/Template_pattern]
	\|-		\|-
	\| Visitor \|\| ~~Defines~~ a new operation ~~to a class~~ without ~~change~~ \|\| [http://en.wikipedia.org/wiki/Visitor_pattern]		\| Visitor \|\| Allow defining a new operation without changing the classes of the elements on which it operates. \|\| [http://en.wikipedia.org/wiki/Visitor_pattern]
	\|}		\|}

Kanke: /* Design Pattern */

2009-10-12T22:42:23Z

Design Pattern

← Older revision		Revision as of 22:42, 12 October 2009
Line 48:		Line 48:
	\| Interpreter \|\| Given a language, specifies how to evaluate sentences using a defined grammar. \|\| [http://en.wikipedia.org/wiki/Interpreter_pattern]		\| Interpreter \|\| Given a language, specifies how to evaluate sentences using a defined grammar. \|\| [http://en.wikipedia.org/wiki/Interpreter_pattern]
	\|-		\|-
	\| Iterator \|\| ~~Sequentially~~ access the elements of a collection \|\| [http://en.wikipedia.org/wiki/Iterator_pattern]		\| Iterator \|\| Iterators is used to access the elements of a collection sequentially without exposing its underlying representation. \|\| [http://en.wikipedia.org/wiki/Iterator_pattern]
	\|-		\|-
	\| Mediator \|\| ~~Defines simplified communication between classes~~ \|\| [http://en.wikipedia.org/wiki/Mediator_pattern]		\| Mediator \|\| Define an object that encapsulates how a set of objects interact to keep objects from referring to each other explicitly. Promote de-coupling and let one vary their interaction independently. \|\| [http://en.wikipedia.org/wiki/Mediator_pattern]
	\|-		\|-
	\| Memento \|\| Capture and ~~restore~~ an object's internal state \|\| [http://en.wikipedia.org/wiki/Memento_pattern]		\| Memento \|\| Capture and externalize an object's internal state for later restoration. \|\| [http://en.wikipedia.org/wiki/Memento_pattern]
	\|-		\|-
	\| Observer \|\| ~~A way of notifying change to a number of classes~~ \|\| [http://en.wikipedia.org/wiki/Observer_pattern]		\| Observer \|\| When one object changes state, all its dependents are notified and updated automatically. \|\| [http://en.wikipedia.org/wiki/Observer_pattern]
	\|-		\|-
	\| State \|\| Alter an object's behavior when its state changes \|\| [http://en.wikipedia.org/wiki/State_pattern]		\| State \|\| Alter an object's behavior like change its class when its internal state changes. \|\| [http://en.wikipedia.org/wiki/State_pattern]
	\|-		\|-
	\| Strategy \|\| Encapsulates an algorithm inside a class \|\| [http://en.wikipedia.org/wiki/Strategy_pattern]		\| Strategy \|\| Encapsulates an algorithm inside a class \|\| [http://en.wikipedia.org/wiki/Strategy_pattern]

Kanke: /* Design Pattern */

2009-10-12T21:42:49Z

Design Pattern

← Older revision		Revision as of 21:42, 12 October 2009
Line 46:		Line 46:
	\| Command \|\| Encapsulate a command request as an object \|\| [http://en.wikipedia.org/wiki/Command_pattern]		\| Command \|\| Encapsulate a command request as an object \|\| [http://en.wikipedia.org/wiki/Command_pattern]
	\|-		\|-
	\| Interpreter \|\| ~~A way~~ to ~~include language elements in~~ a ~~program~~ \|\| [http://en.wikipedia.org/wiki/Interpreter_pattern]		\| Interpreter \|\| Given a language, specifies how to evaluate sentences using a defined grammar. \|\| [http://en.wikipedia.org/wiki/Interpreter_pattern]
	\|-		\|-
	\| Iterator \|\| Sequentially access the elements of a collection \|\| [http://en.wikipedia.org/wiki/Iterator_pattern]		\| Iterator \|\| Sequentially access the elements of a collection \|\| [http://en.wikipedia.org/wiki/Iterator_pattern]

Kanke: /* Design Pattern */

2009-10-12T21:37:51Z

Design Pattern

← Older revision		Revision as of 21:37, 12 October 2009
Line 9:		Line 9:
	{\| border="1"		{\| border="1"
	\|-		\|-
	!Name !! Description		!Name !! Description !! Ref.
	\|-		\|-
	\| <b>Creational Patterns</b> \|\| <b>Deal with object creation mechanisms</b>		\| <b>Creational Patterns</b> \|\| <b>Deal with object creation mechanisms</b>
Line 41:		Line 41:
	\| <b>Behavioral Patterns</b> \|\| <b>Common communication patterns between objects and its realization</b>		\| <b>Behavioral Patterns</b> \|\| <b>Common communication patterns between objects and its realization</b>
	\|-		\|-
	\| Chain of Resp. \|\| ~~A way of passing a~~ request ~~between a chain of~~ objects		\| Chain of Resp. \|\| Add more than one object to handle the request and pass along before the receiving objects to decouple the requester from the receiver objects. \|\| [http://en.wikipedia.org/wiki/Chain_of_responsibility_pattern]
	\|-		\|-
	~~\| Command \|\| Encapsulate a command request as an object~~
	\|-		\|-
	\| ~~Interpreter~~ \|\| ~~A way to include language elements in~~ a ~~program~~		\| Command \|\| Encapsulate a command request as an object \|\| [http://en.wikipedia.org/wiki/Command_pattern]
	\|-		\|-
	\| ~~Iterator~~ \|\| ~~Sequentially access the~~ elements of a ~~collection~~		\| Interpreter \|\| A way to include language elements in a program \|\| [http://en.wikipedia.org/wiki/Interpreter_pattern]
	\|-		\|-
	\| ~~Mediator~~ \|\| ~~Defines simplified communication between classes~~		\| Iterator \|\| Sequentially access the elements of a collection \|\| [http://en.wikipedia.org/wiki/Iterator_pattern]
	\|-		\|-
	\| ~~Memento~~ \|\| ~~Capture and restore an object's internal state~~		\| Mediator \|\| Defines simplified communication between classes \|\| [http://en.wikipedia.org/wiki/Mediator_pattern]
	\|-		\|-
	\| ~~Observer~~ \|\| ~~A way of notifying change to a number of classes~~		\| Memento \|\| Capture and restore an object's internal state \|\| [http://en.wikipedia.org/wiki/Memento_pattern]
	\|-		\|-
	\| ~~State~~ \|\| ~~Alter an object's behavior when its state changes~~		\| Observer \|\| A way of notifying change to a number of classes \|\| [http://en.wikipedia.org/wiki/Observer_pattern]
	\|-		\|-
	\| ~~Strategy~~ \|\| ~~Encapsulates~~ an ~~algorithm inside a class~~		\| State \|\| Alter an object's behavior when its state changes \|\| [http://en.wikipedia.org/wiki/State_pattern]
	\|-		\|-
	\| ~~Template Method~~ \|\| ~~Defer the exact steps of~~ an algorithm to a ~~subclass~~		\| Strategy \|\| Encapsulates an algorithm inside a class \|\| [http://en.wikipedia.org/wiki/Strategy_pattern]
	\|-		\|-
	\| Visitor \|\| Defines a new operation to a class without change		\| Template Method \|\| Defer the exact steps of an algorithm to a subclass \|\| [http://en.wikipedia.org/wiki/Template_pattern]
			\|-
			\| Visitor \|\| Defines a new operation to a class without change \|\| [http://en.wikipedia.org/wiki/Visitor_pattern]
	\|}		\|}

Kanke at 21:27, 12 October 2009

2009-10-12T21:27:50Z

← Older revision		Revision as of 21:27, 12 October 2009
Line 87:		Line 87:


	~~[http://i.cmpnet.com/ddj/ddj/images/ddj9708d/9708df6.gif [2]]~~
	Many software designers view patterns as a form of language-independent design. Pattern-Oriented Software Architectures: A System of Patterns, edited by Frank Buschmann (John Wiley & Sons, 1996), for instance, divides patterns into three main groups -- architectural patterns, design patterns, and idioms. Only the idioms (defined as "low-level patterns specific to a program language") are language dependent -- the other patterns (and the implicit pattern language) rise above the level of programming language, much as the unified modeling language (UML) provides a common way to express designs.		Many software designers view patterns as a form of language-independent design. Pattern-Oriented Software Architectures: A System of Patterns, edited by Frank Buschmann (John Wiley & Sons, 1996), for instance, divides patterns into three main groups -- architectural patterns, design patterns, and idioms. Only the idioms (defined as "low-level patterns specific to a program language") are language dependent -- the other patterns (and the implicit pattern language) rise above the level of programming language, much as the unified modeling language (UML) provides a common way to express designs.

Line 178:		Line 177:
	There are various levels of design recognition for generating repeatable solutions to commonly occurring programming problems in software design. Design patterns in this case have been met with criticism in whether it negates the agile product development process. From our example above we have shown that when implementing patterns across various languages of varying type systems a design pattern may not always resolve common problems efficiently. Thus, the idea of a language independent pattern recognition solution must be evaluated thoroughly when in considering from a static and dynamic point of view.		There are various levels of design recognition for generating repeatable solutions to commonly occurring programming problems in software design. Design patterns in this case have been met with criticism in whether it negates the agile product development process. From our example above we have shown that when implementing patterns across various languages of varying type systems a design pattern may not always resolve common problems efficiently. Thus, the idea of a language independent pattern recognition solution must be evaluated thoroughly when in considering from a static and dynamic point of view.

	== ~~References~~ ==		== Useful Links ==

			* http://en.wikipedia.org/wiki/Type_system
			* http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
	* http://www.dofactory.com/Patterns/Patterns.aspx		* http://www.dofactory.com/Patterns/Patterns.aspx

Kanke: /* Design Pattern */

2009-10-12T21:21:21Z

Design Pattern

← Older revision		Revision as of 21:21, 12 October 2009
Line 25:		Line 25:
	\| <b>Structural Patterns</b> \|\| <b>Realize relationships between entities</b>		\| <b>Structural Patterns</b> \|\| <b>Realize relationships between entities</b>
	\|-		\|-
	\| Adapter \|\| Convert an otherwise incompatible interface of a class into another that clients can work with.		\| Adapter \|\| Convert an otherwise incompatible interface of a class into another that clients can work with. \|\| [http://en.wikipedia.org/wiki/Adapter_pattern]
	\|-		\|-
	\| Bridge \|\| Decouple an interface from its implementation so that the two can vary independently.		\| Bridge \|\| Decouple an interface from its implementation so that the two can vary independently. \|\| [http://en.wikipedia.org/wiki/Bridge_pattern]
	\|-		\|-
	\| Composite \|\| Compose objects into tree structures to represent part-whole hierarchies so they can be treated uniformaly by clients.		\| Composite \|\| Compose objects into tree structures to represent part-whole hierarchies so they can be treated uniformaly by clients. \|\| [http://en.wikipedia.org/wiki/Composite_pattern]
	\|-		\|-
	\| Decorator \|\| Attach additional responsibilities to an object dynamically for extending functionality, while keeping the same interface.		\| Decorator \|\| Attach additional responsibilities to an object dynamically for extending functionality, while keeping the same interface. \|\| [http://en.wikipedia.org/wiki/Decorator_pattern]
	\|-		\|-
	\| Facade \|\| Provide a higher level unified interface to a set of interfaces to make the subsystem easier to use.		\| Facade \|\| Provide a higher level unified interface to a set of interfaces to make the subsystem easier to use. \|\| [http://en.wikipedia.org/wiki/Facade_pattern]
	\|-		\|-
	\| Flyweight \|\| ~~Use sharing to support~~ large numbers of fine-grained objects efficiently.		\| Flyweight \|\| Support large numbers of fine-grained objects efficiently by sharing. \|\| [http://en.wikipedia.org/wiki/Flyweight_pattern]
	\|-		\|-
	\| Proxy \|\| ~~An object representing~~ another object		\| Proxy \|\| Provide a surrogate or interface for another object to control access to it. \|\| [http://en.wikipedia.org/wiki/Proxy_pattern]
	\|-		\|-
	\| <b>Behavioral Patterns</b> \|\| <b>Common communication patterns between objects and its realization</b>		\| <b>Behavioral Patterns</b> \|\| <b>Common communication patterns between objects and its realization</b>

Kanke at 21:10, 12 October 2009

2009-10-12T21:10:59Z

← Older revision		Revision as of 21:10, 12 October 2009
Line 5:		Line 5:
	== Introduction ==		== Introduction ==
	=== Design Pattern ===		=== Design Pattern ===
	A design pattern is a description or template for solving a particular problem under different circumstances. It's a general reusable solution to a commonly occurring problem in software design. Object-oriented design pattern is not a finished product but rather an idea can be realized into code. It specifies the relationships and interactions between classes or objects, and leave the job of specifying the final application classes or objects to the ~~implementor~~.		A design pattern is a description or template for solving a particular problem under different circumstances. It's a general reusable solution to a commonly occurring problem in software design. Object-oriented design pattern is not a finished product but rather an idea can be realized into code. It specifies the relationships and interactions between classes or objects, and leave the job of specifying the final application classes or objects to the implementer.

	~~[http://www.dofactory.com/Patterns/Patterns.aspx [1]]~~
	{\| border="1"		{\| border="1"
	\|-		\|-
Line 22:		Line 21:
	\| Prototype \|\| Create new objects by copying a prototypical instance. \|\| [http://en.wikipedia.org/wiki/Prototype_pattern]		\| Prototype \|\| Create new objects by copying a prototypical instance. \|\| [http://en.wikipedia.org/wiki/Prototype_pattern]
	\|-		\|-
	\| Singleton \|\| Ensure a class only have one single instance existing and accessible globally \|\| [http://en.wikipedia.org/wiki/Prototype_pattern]		\| Singleton \|\| Ensure a class only have one single instance existing and accessible globally. \|\| [http://en.wikipedia.org/wiki/Prototype_pattern]
	\|-		\|-
	\| <b>Structural Patterns</b> \|\| <b>Realize relationships between entities</b>		\| <b>Structural Patterns</b> \|\| <b>Realize relationships between entities</b>
	\|-		\|-
	\| Adapter \|\| ~~Match interfaces~~ of ~~different classes~~		\| Adapter \|\| Convert an otherwise incompatible interface of a class into another that clients can work with.
	\|-		\|-
	\| Bridge \|\| ~~Separates~~ an ~~object’s~~ interface from its implementation		\| Bridge \|\| Decouple an interface from its implementation so that the two can vary independently.
	\|-		\|-
	\| Composite \|\| A tree ~~structure of simple and composite objects~~		\| Composite \|\| Compose objects into tree structures to represent part-whole hierarchies so they can be treated uniformaly by clients.
	\|-		\|-
	\| Decorator \|\| ~~Add~~ responsibilities to ~~objects~~ dynamically		\| Decorator \|\| Attach additional responsibilities to an object dynamically for extending functionality, while keeping the same interface.
	\|-		\|-
	\| Facade \|\| ~~A single class that represents an entire~~ subsystem		\| Facade \|\| Provide a higher level unified interface to a set of interfaces to make the subsystem easier to use.
	\|-		\|-
	\| Flyweight \|\| A fine-grained ~~instance used for efficient sharing~~		\| Flyweight \|\| Use sharing to support large numbers of fine-grained objects efficiently.
	\|-		\|-
	\| Proxy \|\| An object representing another object		\| Proxy \|\| An object representing another object
Line 181:		Line 180:
	== References ==		== References ==

	~~All sources used to create this wiki are linked in the above text~~.		* http://www.dofactory.com/Patterns/Patterns.aspx

Kanke: /* Design Pattern */

2009-10-12T20:52:20Z

Design Pattern

← Older revision		Revision as of 20:52, 12 October 2009
Line 12:		Line 12:
	!Name !! Description		!Name !! Description
	\|-		\|-
	\| <em>Creational Patterns</em> \|\| <em>Deal with object creation mechanisms</em>		\| <b>Creational Patterns</b> \|\| <b>Deal with object creation mechanisms</b>
	\|-		\|-
	\| Abstract Factory \|\| Provide a way to create a families of related/dependent objects without specifying their concrete classes. \|\| [http://en.wikipedia.org/wiki/Abstract_factory_pattern]		\| Abstract Factory \|\| Provide a way to create a families of related/dependent objects without specifying their concrete classes. \|\| [http://en.wikipedia.org/wiki/Abstract_factory_pattern]
Line 24:		Line 24:
	\| Singleton \|\| Ensure a class only have one single instance existing and accessible globally \|\| [http://en.wikipedia.org/wiki/Prototype_pattern]		\| Singleton \|\| Ensure a class only have one single instance existing and accessible globally \|\| [http://en.wikipedia.org/wiki/Prototype_pattern]
	\|-		\|-
	\| Structural Patterns		\| <b>Structural Patterns</b> \|\| <b>Realize relationships between entities</b>
	\|-		\|-
	\| Adapter \|\| Match interfaces of different classes		\| Adapter \|\| Match interfaces of different classes
Line 40:		Line 40:
	\| Proxy \|\| An object representing another object		\| Proxy \|\| An object representing another object
	\|-		\|-
	\| Behavioral Patterns		\| <b>Behavioral Patterns</b> \|\| <b>Common communication patterns between objects and its realization</b>
	\|-		\|-
	\| Chain of Resp. \|\| A way of passing a request between a chain of objects		\| Chain of Resp. \|\| A way of passing a request between a chain of objects