Builder - Revision history

JaroslavTulach at 11:20, 25 August 2009

JaroslavTulach — Tue, 25 Aug 2009 11:20:02 GMT

←Older revision		Revision as of 11:20, 25 August 2009
Line 19:		Line 19:
	<source lang="java" snippet="ServerConnector.builder.creation"/>		<source lang="java" snippet="ServerConnector.builder.creation"/>

-	[[APIDesignPatterns:Builder\|Builder pattern]] evolution characteristics are similar to the ones of the [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern. Yet the clear separation between configuration and functional part of the [[API]] may, in some situations, simplify internal implementation and prevent misuses (calling a ''setter'' after making the connection) of the class.	+	[[APIDesignPatterns:Builder\|Builder pattern]] [[evolution]] characteristics are similar to the ones of the [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern. Yet the clear separation between configuration and functional part of the [[API]] may, in some situations, simplify internal implementation and prevent misuses (calling a ''setter'' after making the connection) of the class.

	<comments/>		<comments/>

JaroslavTulach at 11:19, 25 August 2009

JaroslavTulach — Tue, 25 Aug 2009 11:19:29 GMT

←Older revision		Revision as of 11:19, 25 August 2009
Line 5:		Line 5:
	<source lang="java" snippet="aserverinfo.builder.api"/>		<source lang="java" snippet="aserverinfo.builder.api"/>

-	...and we need a way to establish connection to it. For that purpose we can define additional class that has no ''getters'', no way to obtain its state by external API clients. Instead it offers users of its API only ''setters'' ~~(or in this case cumulative factory methods)~~ allowing the clients to change enough properties before final creation of the connector is done:	+	...and we need a way to establish connection to it. For that purpose we can define additional class that has no ''getters'', no way to obtain its state by external API clients. Instead it offers users of its [[API]] only ''setters'' allowing the clients to change enough properties before final creation of the connector is done:

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

-	~~The API use is not complicated over~~ the ~~case~~ of [[APIDesignPatterns:CumulativeFactory\|cumulative factory]]. ~~Moreover~~ the ~~writer~~ of the ~~API can simplify~~ internals of ~~his~~ '''ServerInfo''' class, as the class is know to never connect directly to any server. The class is just a recipe for creation of the connection:	+	Usually the above methods destructively update the state of the builder object and return it back, so the calls can be chained. Alternatively one can use the [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] and always return new instance of the intermittent build object (more [[Declarative_Programming\|declarative]] approach).
		+
		+	The interesting thing is on the [[Builder]] pattern is simplification of the internals of the '''ServerInfo''' class, as the class is know to never connect directly to any server. The class is just a recipe for creation of the connection:

	<source lang="java" snippet="ServerConnector.builder.creation.verbose"/>		<source lang="java" snippet="ServerConnector.builder.creation.verbose"/>

JaroslavTulach at 09:25, 25 August 2009

JaroslavTulach — Tue, 25 Aug 2009 09:25:44 GMT

←Older revision		Revision as of 09:25, 25 August 2009
Line 1:		Line 1:
-	[[APIDesignPatterns:Builder\|Builder pattern]] is ~~composed from inital configuration~~ [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern phase followed by final call to a [[APIDesignPatterns:Factory\|factory method]]. It is very useful, especially in cases where the intermediate states created by the use of [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] are incomplete and cannot be used by itself. ~~If an~~ additional ~~action~~ (write to disk, establish connnection, etc.) ~~is needed, it makes sense to finish~~ the API calls by final use of [[APIDesignPatterns:Factory\|factory method]].	+	[[APIDesignPatterns:Builder\|Builder pattern]] is an alternative to [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern. While the [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] relies fully on immutability, the initial phase of a [[APIDesignPatterns:Builder\|Builder]] empowers mutability. It is then followed by final call to a [[APIDesignPatterns:Factory\|factory method]] to convert the temporarily mutable object into immutable one. It is very useful, especially in cases where the intermediate states created by the use of [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] are incomplete and cannot be used by itself, or when mutability offers some obvious benefits. For example avoiding additional temporary actions (write to disk, establish connnection, etc.). Then the additional step of ''finishing'' the [[API]] calls by final use of [[APIDesignPatterns:Factory\|factory method]] makes a lot of sense.

	Imagine that we have an API representing a server...		Imagine that we have an API representing a server...

JaroslavTulach at 13:10, 15 November 2008

JaroslavTulach — Sat, 15 Nov 2008 13:10:13 GMT

←Older revision		Revision as of 13:10, 15 November 2008
Line 1:		Line 1:
	[[APIDesignPatterns:Builder\|Builder pattern]] is composed from inital configuration [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern phase followed by final call to a [[APIDesignPatterns:Factory\|factory method]]. It is very useful, especially in cases where the intermediate states created by the use of [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] are incomplete and cannot be used by itself. If an additional action (write to disk, establish connnection, etc.) is needed, it makes sense to finish the API calls by final use of [[APIDesignPatterns:Factory\|factory method]].		[[APIDesignPatterns:Builder\|Builder pattern]] is composed from inital configuration [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern phase followed by final call to a [[APIDesignPatterns:Factory\|factory method]]. It is very useful, especially in cases where the intermediate states created by the use of [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] are incomplete and cannot be used by itself. If an additional action (write to disk, establish connnection, etc.) is needed, it makes sense to finish the API calls by final use of [[APIDesignPatterns:Factory\|factory method]].

-	Imagine that we have an API representing a server:	+	Imagine that we have an API representing a server...

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

-	~~And~~ we need a way to establish connection to it. For that purpose we can define additional class that has no ''getters'', no way to obtain its state ~~via~~ external ~~APIs~~. Instead it offers users of its API only ''setters'' (or in this case cumulative factory methods) allowing the clients to change enough properties before final creation of the connector:	+	...and we need a way to establish connection to it. For that purpose we can define additional class that has no ''getters'', no way to obtain its state by external API clients. Instead it offers users of its API only ''setters'' (or in this case cumulative factory methods) allowing the clients to change enough properties before final creation of the connector is done:

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

-	The use is ~~similar as in~~ case of [[APIDesignPatterns:CumulativeFactory\|cumulative factory]]~~, just~~ the writer of the API can simplify internals of ~~the~~ '''ServerInfo''' class, as it is know to never connect directly, to ~~the~~ server~~, it~~ is just a recipe for creation of the connection:	+	The API use is not complicated over the case of [[APIDesignPatterns:CumulativeFactory\|cumulative factory]]. Moreover the writer of the API can simplify internals of his '''ServerInfo''' class, as the class is know to never connect directly to any server. The class is just a recipe for creation of the connection:

	<source lang="java" snippet="ServerConnector.builder.creation.verbose"/>		<source lang="java" snippet="ServerConnector.builder.creation.verbose"/>

-	The previous snippet is the verbose way to use the API~~, the~~ shorter one liner ~~looks like~~:	+	The previous code snippet shows the verbose way to use the API. The shorter one-liner is also possible:

	<source lang="java" snippet="ServerConnector.builder.creation"/>		<source lang="java" snippet="ServerConnector.builder.creation"/>

-	[[APIDesignPatterns:Builder\|Builder pattern]] evolution characteristics are ~~simpler~~ to [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern, ~~yet~~ in some situations ~~can its use~~ simplify internal implementation of the ~~[[API]]~~.	+	[[APIDesignPatterns:Builder\|Builder pattern]] evolution characteristics are similar to the ones of the [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern. Yet the clear separation between configuration and functional part of the [[API]] may, in some situations, simplify internal implementation and prevent misuses (calling a ''setter'' after making the connection) of the class.

	<comments/>		<comments/>

JaroslavTulach at 13:03, 15 November 2008

JaroslavTulach — Sat, 15 Nov 2008 13:03:24 GMT

←Older revision		Revision as of 13:03, 15 November 2008
Line 1:		Line 1:
-	[[APIDesignPatterns:Builder\|Builder pattern]] is ~~build around~~ configuration [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern followed by final call to a [[APIDesignPatterns:Factory\|factory method]]. It is very useful, especially in cases where the intermediate states created by the use of [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] are incomplete and cannot be used by itself. If an additional action (write to disk, establish connnection, etc.) is needed, it makes sense to finish the API calls by final use of [[APIDesignPatterns:Factory\|factory method]].	+	[[APIDesignPatterns:Builder\|Builder pattern]] is composed from inital configuration [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern phase followed by final call to a [[APIDesignPatterns:Factory\|factory method]]. It is very useful, especially in cases where the intermediate states created by the use of [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] are incomplete and cannot be used by itself. If an additional action (write to disk, establish connnection, etc.) is needed, it makes sense to finish the API calls by final use of [[APIDesignPatterns:Factory\|factory method]].

	Imagine that we have an API representing a server:		Imagine that we have an API representing a server:

JaroslavTulach at 13:01, 15 November 2008

JaroslavTulach — Sat, 15 Nov 2008 13:01:26 GMT

←Older revision		Revision as of 13:01, 15 November 2008
Line 18:		Line 18:

	[[APIDesignPatterns:Builder\|Builder pattern]] evolution characteristics are simpler to [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern, yet in some situations can its use simplify internal implementation of the [[API]].		[[APIDesignPatterns:Builder\|Builder pattern]] evolution characteristics are simpler to [[APIDesignPatterns:CumulativeFactory\|cumulative factory]] pattern, yet in some situations can its use simplify internal implementation of the [[API]].
		+
		+	<comments/>

	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]
	[[Category:APIDesignPatterns:Creational]]		[[Category:APIDesignPatterns:Creational]]

JaroslavTulach: APIDesignPatterns:Builder moved to Builder: With categories, we need shorter names.

JaroslavTulach — Sat, 15 Nov 2008 12:29:36 GMT

APIDesignPatterns:Builder moved to Builder: With categories, we need shorter names.

←Older revision

Revision as of 12:29, 15 November 2008

JaroslavTulach: New page: Builder pattern is build around configuration cumulative factory pattern followed by final call to a [[APIDesignPatter...

JaroslavTulach — Sat, 15 Nov 2008 12:18:19 GMT

New page: Builder pattern is build around configuration cumulative factory pattern followed by final call to a [[APIDesignPatter...

New page

[[APIDesignPatterns:Builder|Builder pattern]] is build around configuration [[APIDesignPatterns:CumulativeFactory|cumulative factory]] pattern followed by final call to a [[APIDesignPatterns:Factory|factory method]]. It is very useful, especially in cases where the intermediate states created by the use of [[APIDesignPatterns:CumulativeFactory|cumulative factory]] are incomplete and cannot be used by itself. If an additional action (write to disk, establish connnection, etc.) is needed, it makes sense to finish the API calls by final use of [[APIDesignPatterns:Factory|factory method]].

Imagine that we have an API representing a server:

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

And we need a way to establish connection to it. For that purpose we can define additional class that has no ''getters'', no way to obtain its state via external APIs. Instead it offers users of its API only ''setters'' (or in this case cumulative factory methods) allowing the clients to change enough properties before final creation of the connector:

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

The use is similar as in case of [[APIDesignPatterns:CumulativeFactory|cumulative factory]], just the writer of the API can simplify internals of the '''ServerInfo''' class, as it is know to never connect directly, to the server, it is just a recipe for creation of the connection:

<source lang="java" snippet="ServerConnector.builder.creation.verbose"/>

The previous snippet is the verbose way to use the API, the shorter one liner looks like:

<source lang="java" snippet="ServerConnector.builder.creation"/>

[[APIDesignPatterns:Builder|Builder pattern]] evolution characteristics are simpler to [[APIDesignPatterns:CumulativeFactory|cumulative factory]] pattern, yet in some situations can its use simplify internal implementation of the [[API]].

[[Category:APIDesignPatterns]]
[[Category:APIDesignPatterns:Creational]]