Object-Oriented Design Patterns - Revision history

Logmanoriginal: Redirect to Category:Object-Oriented Design Pattern

2020-03-30T16:56:00Z

Redirect to Category:Object-Oriented Design Pattern

← Older revision		Revision as of 16:56, 30 March 2020
Line 1:		Line 1:
	'''Object-Oriented Design Patterns''' mimic many of the basic [[Design Patterns Overview\|design patterns]]. Here are a few of the simple OO design patterns:<ref>"3 Simple Object-Oriented Design Patterns in LabVIEW" by Elijah Kerry, National Instruments (http://www.ni.com/newsletter/51506/en/)		#REDIRECT [[Category:Object-Oriented Design Pattern]]
	~~</ref>~~
	~~# Factory Pattern~~
	~~# Command Pattern~~
	# ~~Decorator Pattern~~

	~~See~~ [[:Category:Object-Oriented Design Pattern~~\|Object-Oriented Design Pattern]] for a complete list of object-oriented design patterns.~~

	~~== Factory Pattern ==~~
	The factory pattern has been referred to as the most commonly used pattern in modern languages. A factory creates objects without exposing the instantiation logic to the client and refers to the newly created object through a common interface. It’s generally used in applications that have a plug-in component, or some functionality that needs to be loaded dynamically at run time. This requires the definition of a generic parent object, which encapsulates functionality that can then be reused and even extended by children.
	~~[[File:Factory Pattern.png\|358x358px\|frameless\|center\|Factory Pattern]]~~
	With this simple LabVIEW code snippet, the application can load children of “Generic Plugin.lvclass” at run time without having to be aware of the children or their specific functionality beforehand.

	~~== Command Pattern ==~~
	The command pattern is especially relevant to LabVIEW programmers, as it can help address some of the challenges associated with sending a command or message between processes. This typically requires coupling the command with any data required by that command to execute, which is often achieved using a cluster containing the command as an enumerated constant and a variant for an arbitrary data type (see [[Queued Message Handler (QMH) Design Pattern\|Queued Message Handler]] and [[Actor Framework]]). The command pattern instead creates a new instance of a child class to represent the specific command, which defines the information to be associated with the command within the private data.
	~~[[File:Command Pattern.png\|590x590px\|frameless\|center\|Command Pattern]]~~
	The command pattern uses child classes to represent commands or messages that need to be sent to a consumer loop. Data associated with the command is stored within the object, and the execute method is overridden by each specific class to implement the functionality required to handle the specific message.

	~~== Decorator Pattern ==~~
	Developers often design applications knowing that more functionality will need to be added at a later date, but this is best done without the risk associated with modifying tested, pre-existing code. The decorator pattern can help in such a scenario by making it possible to add responsibilities and information dynamically to an object.
	~~[[File:Decorator Pattern.png\|507x507px\|frameless\|center\|Decorator Pattern]]~~
	The original object, which is a dark roast coffee, is decorated with additional properties by children of a separate hierarchy for condiments. The set of condiments can dynamically be expanded without modifying peers. Invoking the methods to get the cost and the description recursively iterates through all the decorations to aggregate the total values.

	~~== Articles ==~~
	[https://forums.ni.com/t5/Example-Program-Drafts/Applying-Common-Object-Oriented-OO-Design-Patterns-to-LabVIEW/ta-p/3510571 "Applying Common Object-Oriented (OO) Design Patterns to LabVIEW"] - by Elijah Kerry, National Instruments

	''The seminal text on design patterns appeared in 1995: Design Patterns by Gamma, Helm, Johnson and Vlissides. This text is colloquially known as “the Gang of Four book.” This text focused on object-oriented design patterns, specifically those that could be implemented using C++. Many of those patterns are predicated on a by-reference model for objects. As such they apply very well to classes made with the GOOP Toolkit (or any of the several other GOOP implementations for LabVIEW). LabVIEW classes, added in LV8.2, use by-value syntax in order to be dataflow safe. This means that the known patterns of object-oriented programming must be adapted, and new patterns must be identified. This document describes the LabVOOP-specific patterns I have identified thus far. -Stephen Loftus-Mercer''

	~~== References ==~~
	~~<references />~~

	~~[[Category:Design patterns]]~~
	~~[[Category:Object-Oriented Programming~~]]

Logmanoriginal: Add link to the object-oriented design pattern category

2020-03-29T17:35:04Z

Add link to the object-oriented design pattern category

← Older revision		Revision as of 17:35, 29 March 2020
Line 4:		Line 4:
	# Command Pattern		# Command Pattern
	# Decorator Pattern		# Decorator Pattern

			See [[:Category:Object-Oriented Design Pattern\|Object-Oriented Design Pattern]] for a complete list of object-oriented design patterns.

	== Factory Pattern ==		== Factory Pattern ==

Q at 20:41, 11 November 2018

2018-11-11T20:41:06Z

← Older revision		Revision as of 20:41, 11 November 2018
Line 1:		Line 1:
	'''Object-Oriented Design Patterns''' mimic many of the basic [[Design Patterns\|design patterns]]. Here are a few of the simple OO design patterns:<ref>"3 Simple Object-Oriented Design Patterns in LabVIEW" by Elijah Kerry, National Instruments (http://www.ni.com/newsletter/51506/en/)		'''Object-Oriented Design Patterns''' mimic many of the basic [[Design Patterns Overview\|design patterns]]. Here are a few of the simple OO design patterns:<ref>"3 Simple Object-Oriented Design Patterns in LabVIEW" by Elijah Kerry, National Instruments (http://www.ni.com/newsletter/51506/en/)
	</ref>		</ref>
	# Factory Pattern		# Factory Pattern
Line 29:		Line 29:

	[[Category:Design patterns]]		[[Category:Design patterns]]
	~~[[Category:Object-Oriented Programming]]~~
	[[Category:Object-Oriented Programming]]		[[Category:Object-Oriented Programming]]

Q: Added content from the FANDOM site.

2018-11-11T20:40:32Z

Added content from the FANDOM site.

New page

'''Object-Oriented Design Patterns''' mimic many of the basic [[Design Patterns|design patterns]]. Here are a few of the simple OO design patterns:<ref>"3 Simple Object-Oriented Design Patterns in LabVIEW" by Elijah Kerry, National Instruments (http://www.ni.com/newsletter/51506/en/)
</ref>
# Factory Pattern
# Command Pattern
# Decorator Pattern

== Factory Pattern ==
The factory pattern has been referred to as the most commonly used pattern in modern languages. A factory creates objects without exposing the instantiation logic to the client and refers to the newly created object through a common interface. It’s generally used in applications that have a plug-in component, or some functionality that needs to be loaded dynamically at run time. This requires the definition of a generic parent object, which encapsulates functionality that can then be reused and even extended by children.
[[File:Factory Pattern.png|358x358px|frameless|center|Factory Pattern]]
With this simple LabVIEW code snippet, the application can load children of “Generic Plugin.lvclass” at run time without having to be aware of the children or their specific functionality beforehand.

== Command Pattern ==
The command pattern is especially relevant to LabVIEW programmers, as it can help address some of the challenges associated with sending a command or message between processes. This typically requires coupling the command with any data required by that command to execute, which is often achieved using a cluster containing the command as an enumerated constant and a variant for an arbitrary data type (see [[Queued Message Handler (QMH) Design Pattern|Queued Message Handler]] and [[Actor Framework]]). The command pattern instead creates a new instance of a child class to represent the specific command, which defines the information to be associated with the command within the private data.
[[File:Command Pattern.png|590x590px|frameless|center|Command Pattern]]
The command pattern uses child classes to represent commands or messages that need to be sent to a consumer loop. Data associated with the command is stored within the object, and the execute method is overridden by each specific class to implement the functionality required to handle the specific message.

== Decorator Pattern ==
Developers often design applications knowing that more functionality will need to be added at a later date, but this is best done without the risk associated with modifying tested, pre-existing code. The decorator pattern can help in such a scenario by making it possible to add responsibilities and information dynamically to an object.
[[File:Decorator Pattern.png|507x507px|frameless|center|Decorator Pattern]]
The original object, which is a dark roast coffee, is decorated with additional properties by children of a separate hierarchy for condiments. The set of condiments can dynamically be expanded without modifying peers. Invoking the methods to get the cost and the description recursively iterates through all the decorations to aggregate the total values.

== Articles ==
[https://forums.ni.com/t5/Example-Program-Drafts/Applying-Common-Object-Oriented-OO-Design-Patterns-to-LabVIEW/ta-p/3510571 "Applying Common Object-Oriented (OO) Design Patterns to LabVIEW"] - by Elijah Kerry, National Instruments

''The seminal text on design patterns appeared in 1995: Design Patterns by Gamma, Helm, Johnson and Vlissides. This text is colloquially known as “the Gang of Four book.” This text focused on object-oriented design patterns, specifically those that could be implemented using C++. Many of those patterns are predicated on a by-reference model for objects. As such they apply very well to classes made with the GOOP Toolkit (or any of the several other GOOP implementations for LabVIEW). LabVIEW classes, added in LV8.2, use by-value syntax in order to be dataflow safe. This means that the known patterns of object-oriented programming must be adapted, and new patterns must be identified. This document describes the LabVOOP-specific patterns I have identified thus far. -Stephen Loftus-Mercer''

== References ==
<references />

[[Category:Design patterns]]
[[Category:Object-Oriented Programming]]
[[Category:Object-Oriented Programming]]