CumulativeFactory - Revision history

JaroslavTulach: APIDesignPatterns:CumulativeFactory moved to CumulativeFactory: Shorter names for use with categories

2008-11-15T12:30:24Z

APIDesignPatterns:CumulativeFactory moved to CumulativeFactory: Shorter names for use with categories

←Older revision

Revision as of 12:30, 15 November 2008

JaroslavTulach at 11:07, 15 November 2008

2008-11-15T11:07:50Z

←Older revision		Revision as of 11:07, 15 November 2008
Line 13:		Line 13:
	This pattern is based on one ''real'' factory method that creates base version of the object and many instance ''cloning'' methods that take the values in provided ''prototype'' instance, copy them and modify just one attribute, returning new clone. The usage can then chain the cloning to obtain instances with all desired attributes:		This pattern is based on one ''real'' factory method that creates base version of the object and many instance ''cloning'' methods that take the values in provided ''prototype'' instance, copy them and modify just one attribute, returning new clone. The usage can then chain the cloning to obtain instances with all desired attributes:

-	<source lang="java" snippet="~~aserverinfo~~.cumulative.creation"/>	+	<source lang="java" snippet="ServerConnector.cumulative.creation"/>

-	This pattern keeps the [[Declarative Programming]] benefits, while eliminating many overloaded factory methods.	+	This pattern keeps the [[Declarative Programming]] benefits, while eliminating many overloaded factory methods. Similar patterns include [[APIDesignPatterns:Builder]] or plain [[APIDesignPatterns:Factory]]

	<comments/>		<comments/>
		+
		+	[[Category:APIDesignPatterns]]
		+	[[Category:APIDesignPatterns:Creational]]

JaroslavTulach at 17:44, 9 November 2008

2008-11-09T17:44:43Z

←Older revision		Revision as of 17:44, 9 November 2008
Line 3:		Line 3:
	<source lang="java" snippet="aserverinfo.api"/>		<source lang="java" snippet="aserverinfo.api"/>

-	Now you may want to let the API users modify these fields. One option is to provide setters for each getter. However that immediately turns instances of the '''AServerInfo''' class into mutable objects. As lifecycle of mutable objects is more complicated and as the simpler API the better, it may make sense to search for alternatives. One of ~~the~~ is regular factory with a single factory method:	+	Now you may want to let the API users modify these fields. One option is to provide setters for each getter. However that immediately turns instances of the '''AServerInfo''' class into mutable objects. As lifecycle of mutable objects is more complicated and as the simpler API semantics the better, it may make sense to search for alternatives. One of them is regular factory with a single factory method:

	<source lang="java" snippet="aserverinfo.regularcreate"/>		<source lang="java" snippet="aserverinfo.regularcreate"/>

JaroslavTulach: New page: Cumulative Factory is pattern that allows the API Designers get benefits of getters and setters while explorin...

2008-11-09T15:27:38Z

New page: Cumulative Factory is pattern that allows the API Designers get benefits of getters and setters while explorin...

New page

[[APIDesignPatterns:CumulativeFactory|Cumulative Factory]] is pattern that allows the API Designers get benefits of [[APIDesignPatterns:GetterAndSetter|getters and setters]] while exploring the benefits of [[Declarative Programming]]. Imagine that you have an API with getters and few callable methods:

<source lang="java" snippet="aserverinfo.api"/>

Now you may want to let the API users modify these fields. One option is to provide setters for each getter. However that immediately turns instances of the '''AServerInfo''' class into mutable objects. As lifecycle of mutable objects is more complicated and as the simpler API the better, it may make sense to search for alternatives. One of the is regular factory with a single factory method:

<source lang="java" snippet="aserverinfo.regularcreate"/>

This is indeed acceptable solution, yet it suffers from enormous duplication of factory methods. As the API is evolving, it adds more and more getters and each such addition requires new overloaded version of the factory method. This proliferation of many methods with same name and different arguments may not be fully desirable. In such case, one can benefit from using [[APIDesignPatterns:CumulativeFactory|Cumulative Factory]]:

<source lang="java" snippet="aserverinfo.cumulative.factory"/>

This pattern is based on one ''real'' factory method that creates base version of the object and many instance ''cloning'' methods that take the values in provided ''prototype'' instance, copy them and modify just one attribute, returning new clone. The usage can then chain the cloning to obtain instances with all desired attributes:

<source lang="java" snippet="aserverinfo.cumulative.creation"/>

This pattern keeps the [[Declarative Programming]] benefits, while eliminating many overloaded factory methods.

<comments/>