Thomas Linder Puls: link->italics

2013-08-22T09:04:22Z

link->italics

← Older revision		Revision as of 11:04, 22 August 2013
Line 1:		Line 1:
	From [[wikipedia::Abstract factory pattern]]:		From [[wikipedia::Abstract factory pattern]]:

	:A software ~~[[Design pattern\|~~design pattern]], the '''Abstract Factory Pattern''' provides a way to encapsulate a group of individual ~~[[Factory method pattern\|~~factories]] that have a common theme. In normal usage, the client software would create a concrete implementation of the abstract factory and then use the generic ~~[[Interface\|~~interface]]s to create the concrete ~~[[Object\|~~object]]s that are part of the theme. The [[client~~\|client]]~~ does not know (nor care) about which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from its general usage.		:A software ''design pattern'', the '''Abstract Factory Pattern''' provides a way to encapsulate a group of individual ''factories'' that have a common theme. In normal usage, the client software would create a concrete implementation of the abstract factory and then use the generic ''interface''s to create the concrete ''object''s that are part of the theme. The ''client'' does not know (nor care) about which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from its general usage.

	== Example ==		== Example ==

Thomas Linder Puls: Initial text

2007-09-30T22:54:28Z

Initial text

New page

From [[wikipedia::Abstract factory pattern]]:

:A software [[Design pattern|design pattern]], the '''Abstract Factory Pattern''' provides a way to encapsulate a group of individual [[Factory method pattern|factories]] that have a common theme. In normal usage, the client software would create a concrete implementation of the abstract factory and then use the generic [[Interface|interface]]s to create the concrete [[Object|object]]s that are part of the theme. The [[client|client]] does not know (nor care) about which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from its general usage.

== Example ==

A program must work with one of two different GUI systems: '''win''' or '''osx'''. Each of the GUI systems provides '''button'''s and '''edit''' controls. The controls are represented by the same interfaces in the two GUI systems, but different classes:

:{| {{prettytable}}
! interface
! win class
! osx class
|-
| button
| winButton : button
| osxButton : button
|-
| edit
| winEdit : edit
| osxEdit : edit
|}

So when we use the '''win''' system, we must use the win- classes; and when we use the '''osx''' system, we must use the osx- classes. Rather than testing for GUI system each time we want to create a button or edit control, we use an ''abstract factory''.

The abstract factory is an object that can create (i.e. manufacture) buttons and edit controls:

<vip>interface guiFactory
predicates
createButton : () -> button NewButton.
createEdit : () -> edit Edit.
end interface guiFactory</vip>

We implement two factories, one for win- controls:

<vip>class winFactory : guiFactory
end class winFactory</vip>

<vip>implement winFactory
clauses
createButton() = winButton::new().
clauses
createEdit() = winEdit::new().
end implement winFactory</vip>

and one for osx- controls:

<vip>class osxFactory : guiFactory
end class osxFactory</vip>

<vip>implement osxFactory
clauses
createButton() = osxButton::new().
clauses
createEdit() = osxEdit::new().
end implement osxFactory</vip>

Now we can some where create either a '''win'''-factory or an '''osx'''-factory, and in the rest of the program we will create controls using this factory.

The goal here is just for illustrative purposes; in a real program the GUI system would have to be initialized, and the button must be drawn somewhere.

<vip>goal
if 1 = config::getAttribute("OS_TYPE") then
GuiFactory = winFactory::new()
else
GuiFactory = osxFactory::new()
end if,
Button = GuiFactory:createButton(),
Button:setText("Play"),
Button:paint().</vip>

== Additional Notes ==

#In the example above we create one factory at the very start of the program and retain it throughout the entire execution. But in other setup's you may create several factories for each their purpose, or create factories that are only temporarily and then disposed again. Consider for example a '''print''' version of the factory above. You might create an instance of this factory, when you want to print a "dialog" and then dispose it again once you have printed the dialog. So this factory will only live temporarily and it may coexist with one of the other factories.
#The client software does not have any knowledge about the concrete factories. Particularly, it does not know how many there are, the name, purpose or any other characteristics about them.

== References ==

*[[wikipedia:Abstract factory pattern]]
*[[wikipedia:Design_pattern_%28computer_science%29|wikipedia:Design pattern (computer science)]]

[[Category:Design Pattern]]

Abstract factory pattern - Revision history

Thomas Linder Puls: link->italics

Thomas Linder Puls: Initial text