WhiningBuilder - Revision history

JaroslavTulach: /* Summary */

2016-06-26T19:54:50Z

Summary

←Older revision		Revision as of 19:54, 26 June 2016
Line 121:		Line 121:
	=== Summary ===		=== Summary ===

-	Using [[checked exception]] to track essential attributes ~~that yet need~~ to ~~be provided~~ is a nice and no-overhead way to co-relate the requested runtime behavior with compiler and let users know at compile time that their code is wrong and needs additional tweaks. Evolution of this pattern works nicely with respect to [[binary compatibility]] in [[Java]] thanks to [[erasure]] of generic types.	+	Using [[checked exception]] to track essential attributes and to whine when they aren't set is a nice and no-overhead way to co-relate the requested runtime behavior with compiler and let users know at compile time that their code is wrong and needs additional tweaks. Evolution of this pattern works nicely with respect to [[binary compatibility]] in [[Java]] thanks to [[erasure]] of generic types.

JaroslavTulach: /* Evolution */

2016-06-26T19:51:12Z

Evolution

←Older revision		Revision as of 19:51, 26 June 2016
Line 108:		Line 108:
	=== [[Evolution]] ===		=== [[Evolution]] ===

-	An interesting question from an [[evolution]] point of view: what happens when we need to add new essential attribute? Obviously, if we want 100% [[BackwardCompatibility]] then we should add new [[builder]] class:	+	An interesting question from an [[evolution]] point of view: what happens when we need to add a new essential attribute? Obviously, if we want 100% [[BackwardCompatibility]] then we should add new [[builder]] class:

	<source lang="java">		<source lang="java">

JaroslavTulach: /* Drawbacks */

2016-06-26T19:01:26Z

Drawbacks

←Older revision		Revision as of 19:01, 26 June 2016
Line 93:		Line 93:
	=== Drawbacks ===		=== Drawbacks ===

-	The biggest strength of this pattern - e.g. '''N''' independent conditions is also ~~the~~ biggest flaw: Imagine [[clueless]] users seeing the signature with n-[[exception]] type parameters! They would be scared. On the other hand, the typical usage of the [[builder]] pattern doesn't expose the type variables at all:	+	The biggest strength of this pattern - e.g. '''N''' independent conditions is also its biggest flaw: Imagine [[clueless]] users seeing the signature with n-[[exception]] type parameters! They would be scared. On the other hand, the typical usage of the [[builder]] pattern doesn't expose the type variables at all:

	<source lang="java">		<source lang="java">

JaroslavTulach: /* Drawbacks */

2016-06-26T19:00:55Z

Drawbacks

←Older revision		Revision as of 19:00, 26 June 2016
Line 93:		Line 93:
	=== Drawbacks ===		=== Drawbacks ===

-	The biggest strength of this pattern - e.g. '''N''' independent ~~condition~~ is also the biggest flaw: Imagine [[clueless]] users seeing the signature with n-[[exception]] type parameters! They would be scared. On the other hand, the typical usage of the [[builder]] pattern doesn't expose the type variables at all:	+	The biggest strength of this pattern - e.g. '''N''' independent conditions is also the biggest flaw: Imagine [[clueless]] users seeing the signature with n-[[exception]] type parameters! They would be scared. On the other hand, the typical usage of the [[builder]] pattern doesn't expose the type variables at all:

	<source lang="java">		<source lang="java">

JaroslavTulach: /* Why Does It Work? */

2016-06-26T19:00:40Z

Why Does It Work?

←Older revision		Revision as of 19:00, 26 June 2016
Line 89:		Line 89:
	</source>		</source>

-	Each of the '''E'''-th type parameter is representing independent single condition: Was the associated attribute set or not? All of the conditions need to be satisfied otherwise the '''build()''' method keeps throwing a [[checked exception]]. This kind of ''or-behavior'' is impossible to achieve with a single return type in [[Java]] type system.	+	Each of the '''E'''-th type parameter is representing independent single condition and can be used for whining: Was the associated attribute set or not? All of the conditions need to be satisfied otherwise the '''build()''' method keeps whining - e.g. throwing a [[checked exception]]. This kind of ''or-behavior'' is impossible to achieve with a single return type in [[Java]] type system.

	=== Drawbacks ===		=== Drawbacks ===

JaroslavTulach: /* Why Does It Work? */

2016-06-26T18:59:38Z

Why Does It Work?

←Older revision		Revision as of 18:59, 26 June 2016
Line 78:		Line 78:
	=== Why Does It Work? ===		=== Why Does It Work? ===

-	The [[ChameleonBuilder]] works only with a single essential attribute because each attribute can influence only a single generic type. The reason why ~~this new~~ pattern works is that one method can have unlimited number of {{JDK\|java/lang\|Exception}}s in its '''throws''' clause. Depending on the number of essential attributes one defines '''N''' type parameters:	+	The [[ChameleonBuilder]] works only with a single essential attribute because each attribute can influence only a single generic type. The reason why the [[WhiningBuilder]] pattern works is that one method can have unlimited number of {{JDK\|java/lang\|Exception}}s in its '''throws''' clause. Depending on the number of essential attributes one defines '''N''' type parameters:

	<source lang="java">		<source lang="java">

JaroslavTulach: /* Multiple Throws */

2016-06-26T18:58:17Z

Multiple Throws

←Older revision		Revision as of 18:58, 26 June 2016
Line 53:		Line 53:
	one gets a compilation error, as the [[builder]] ''whines''! Its '''build''' method throws a [[checked exception]]. Even if one specifies '''name''', the error still remains. Only if both '''name''' and '''mimeType''' are specified the [[checked exception]]s go away (as they are replaced by runtime [[exception]]s) and the compilation succeeds.		one gets a compilation error, as the [[builder]] ''whines''! Its '''build''' method throws a [[checked exception]]. Even if one specifies '''name''', the error still remains. Only if both '''name''' and '''mimeType''' are specified the [[checked exception]]s go away (as they are replaced by runtime [[exception]]s) and the compilation succeeds.

-	The runtime and compile time aspects work in orchestration: if a [[checked exception]] is reported - it will also be thrown. E.g. trying to put a '''try'''/'''catch''' block around ~~the~~ the '''build()''' call makes no sense. If the [[exception]] is declared, it will really be generated.	+	The runtime and compile time aspects work in orchestration: if a [[checked exception]] is reported - it will also be thrown. E.g. trying to put a '''try'''/'''catch''' block around the '''build()''' call makes no sense. If the [[exception]] is declared, it will really be generated.

	=== Explaining Why ===		=== Explaining Why ===

JaroslavTulach: /* Multiple Throws */

2016-06-26T18:57:06Z

Multiple Throws

←Older revision		Revision as of 18:57, 26 June 2016
Line 51:		Line 51:
	</source>		</source>

-	one gets a compilation error, as the build method throws a [[checked exception]]. Even if one specifies '''name''', the error still remains. Only if both '''name''' and '''mimeType''' are specified the [[checked exception]]s go away (as they are replaced by runtime [[exception]]s) and the compilation succeeds.	+	one gets a compilation error, as the [[builder]] ''whines''! Its '''build''' method throws a [[checked exception]]. Even if one specifies '''name''', the error still remains. Only if both '''name''' and '''mimeType''' are specified the [[checked exception]]s go away (as they are replaced by runtime [[exception]]s) and the compilation succeeds.

	The runtime and compile time aspects work in orchestration: if a [[checked exception]] is reported - it will also be thrown. E.g. trying to put a '''try'''/'''catch''' block around the the '''build()''' call makes no sense. If the [[exception]] is declared, it will really be generated.		The runtime and compile time aspects work in orchestration: if a [[checked exception]] is reported - it will also be thrown. E.g. trying to put a '''try'''/'''catch''' block around the the '''build()''' call makes no sense. If the [[exception]] is declared, it will really be generated.

JaroslavTulach: ResistingBuilder moved to WhiningBuilder: Whine reflects the continuous complaining nature of the builder.

2016-06-26T18:55:28Z

ResistingBuilder moved to WhiningBuilder: Whine reflects the continuous complaining nature of the builder.

←Older revision

Revision as of 18:55, 26 June 2016

JaroslavTulach: /* Multiple Throws */

2016-06-20T06:32:02Z

Multiple Throws

←Older revision		Revision as of 06:32, 20 June 2016
Line 51:		Line 51:
	</source>		</source>

-	one gets a compilation error, as the build method throws a [[checked exception]]. Even if one specifies '''name''', the error still remains. Only if both '''name''' and '''mimeType''' are specified the [[checked exception]]s go away (as they are replaced by runtime [[exception]]s).	+	one gets a compilation error, as the build method throws a [[checked exception]]. Even if one specifies '''name''', the error still remains. Only if both '''name''' and '''mimeType''' are specified the [[checked exception]]s go away (as they are replaced by runtime [[exception]]s) and the compilation succeeds.

	The runtime and compile time aspects work in orchestration: if a [[checked exception]] is reported - it will also be thrown. E.g. trying to put a '''try'''/'''catch''' block around the the '''build()''' call makes no sense. If the [[exception]] is declared, it will really be generated.		The runtime and compile time aspects work in orchestration: if a [[checked exception]] is reported - it will also be thrown. E.g. trying to put a '''try'''/'''catch''' block around the the '''build()''' call makes no sense. If the [[exception]] is declared, it will really be generated.