Case Study of Writing the Extensible Visitor Pattern - Revision history

JaroslavTulach: /* Have You Ever Wondered...? */

JaroslavTulach — Wed, 04 Nov 2009 06:46:01 GMT

Have You Ever Wondered...?

←Older revision		Revision as of 06:46, 4 November 2009
Line 2:		Line 2:

	Do you wonder whether knowledge of proper design patterns makes you good API designer? Yes and no. Of course knowing regular design patterns simplifies communication, understanding, etc. However there are hidden catches. Not every design pattern belongs among [[APIDesignPatterns]] - it may not be ready for evolution. For example the well known [[wikipedia::Visitor_pattern\|Visitor pattern]] is really not evolvable easily as analysed by [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]].		Do you wonder whether knowledge of proper design patterns makes you good API designer? Yes and no. Of course knowing regular design patterns simplifies communication, understanding, etc. However there are hidden catches. Not every design pattern belongs among [[APIDesignPatterns]] - it may not be ready for evolution. For example the well known [[wikipedia::Visitor_pattern\|Visitor pattern]] is really not evolvable easily as analysed by [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]].
		+
		+	== [[Visitor\|Tripple Dispatch]] ==
		+
		+	{{:Visitor}}

JaroslavTulach: /* Tripple Dispatch */

JaroslavTulach — Wed, 04 Nov 2009 06:45:32 GMT

Tripple Dispatch

←Older revision		Revision as of 06:45, 4 November 2009
Line 2:		Line 2:

	Do you wonder whether knowledge of proper design patterns makes you good API designer? Yes and no. Of course knowing regular design patterns simplifies communication, understanding, etc. However there are hidden catches. Not every design pattern belongs among [[APIDesignPatterns]] - it may not be ready for evolution. For example the well known [[wikipedia::Visitor_pattern\|Visitor pattern]] is really not evolvable easily as analysed by [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]].		Do you wonder whether knowledge of proper design patterns makes you good API designer? Yes and no. Of course knowing regular design patterns simplifies communication, understanding, etc. However there are hidden catches. Not every design pattern belongs among [[APIDesignPatterns]] - it may not be ready for evolution. For example the well known [[wikipedia::Visitor_pattern\|Visitor pattern]] is really not evolvable easily as analysed by [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]].
-
-	~~== Tripple Dispatch ==~~
-
-	The [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]] discusses various approaches to implement [[visitor]] in an evolvable [[API]]. The learning path itself is important, but to stress the important point, here is the code for the final solution of the [[expression problem]]:
-
-	~~<source lang="java" snippet="visitor.clientprovider.v1"/>~~
-
-	The solution is using [[Java]] interfaces to represent expression elements and yet it is fully evolvable (one can always define new expression element interface). [[Visitor]] is not just a single class, but one [[Java]] interface and one [[Java]] final class. [[Visitor]]s written using this style are easily extensible. For example when adding support for ''Minus'' operation in version 2.0 one just adds:
-
-	~~<source lang="java" snippet="visitor.clientprovider.v2"/>~~
-
-	This is the most flexible solution. It uses a form of ''tripple'' dispatch - e.g. the final visit method called on the (implementation of the [[visitor]] interface) is determined by the expression type, version of the expression language and implementation of the [[visitor]] interface:
-
-	~~<source lang="java" snippet="visitor.clientprovider.dispatch.v3.l2"/>~~
-
-	This solution to the [[expression problem]] is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] is enriched by new and new ''dispatch'' methods with every version. The interface part of [[visitor]] is immutable, a fixed point, which stays the same for those who implement it. Each version defines its own unique interface (according to the list of expression types it supports). The internals of the [[API]] then bridge the ''dispatch'' methods to appropriate interface ''visit'' methods.
-
-	~~<comments/>~~
-
-	~~[[Category:APIDesignPatterns]]~~
-	~~[[Category:APIDesignPatterns:Evolution]]~~

JaroslavTulach: /* Tripple Dispatch */

JaroslavTulach — Wed, 04 Nov 2009 06:42:55 GMT

Tripple Dispatch

←Older revision		Revision as of 06:42, 4 November 2009
Line 9:		Line 9:
	<source lang="java" snippet="visitor.clientprovider.v1"/>		<source lang="java" snippet="visitor.clientprovider.v1"/>

-	[[Visitor]]s written using this style are easily extensible~~, by~~ adding ~~new expression types as shown~~ in version 2.0:	+	The solution is using [[Java]] interfaces to represent expression elements and yet it is fully evolvable (one can always define new expression element interface). [[Visitor]] is not just a single class, but one [[Java]] interface and one [[Java]] final class. [[Visitor]]s written using this style are easily extensible. For example when adding support for ''Minus'' operation in version 2.0 one just adds:

	<source lang="java" snippet="visitor.clientprovider.v2"/>		<source lang="java" snippet="visitor.clientprovider.v2"/>

-	This is the most flexible solution. It uses form of ''tripple'' dispatch - e.g. the final visit method is ~~defined~~ by the expression type, version of the expression language and implementation of the [[visitor]] interface:	+	This is the most flexible solution. It uses a form of ''tripple'' dispatch - e.g. the final visit method called on the (implementation of the [[visitor]] interface) is determined by the expression type, version of the expression language and implementation of the [[visitor]] interface:

	<source lang="java" snippet="visitor.clientprovider.dispatch.v3.l2"/>		<source lang="java" snippet="visitor.clientprovider.dispatch.v3.l2"/>

-	This solution to the [[expression problem]] is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]].	+	This solution to the [[expression problem]] is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] is enriched by new and new ''dispatch'' methods with every version. The interface part of [[visitor]] is immutable, a fixed point, which stays the same for those who implement it. Each version defines its own unique interface (according to the list of expression types it supports). The internals of the [[API]] then bridge the ''dispatch'' methods to appropriate interface ''visit'' methods.
		+
		+	<comments/>

	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]
	[[Category:APIDesignPatterns:Evolution]]		[[Category:APIDesignPatterns:Evolution]]

JaroslavTulach: /* Have You Ever Wondered...? */

JaroslavTulach — Tue, 03 Nov 2009 08:15:08 GMT

Have You Ever Wondered...?

←Older revision		Revision as of 08:15, 3 November 2009
Line 2:		Line 2:

	Do you wonder whether knowledge of proper design patterns makes you good API designer? Yes and no. Of course knowing regular design patterns simplifies communication, understanding, etc. However there are hidden catches. Not every design pattern belongs among [[APIDesignPatterns]] - it may not be ready for evolution. For example the well known [[wikipedia::Visitor_pattern\|Visitor pattern]] is really not evolvable easily as analysed by [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]].		Do you wonder whether knowledge of proper design patterns makes you good API designer? Yes and no. Of course knowing regular design patterns simplifies communication, understanding, etc. However there are hidden catches. Not every design pattern belongs among [[APIDesignPatterns]] - it may not be ready for evolution. For example the well known [[wikipedia::Visitor_pattern\|Visitor pattern]] is really not evolvable easily as analysed by [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]].
		+
		+	== Tripple Dispatch ==
		+
		+	The [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]] discusses various approaches to implement [[visitor]] in an evolvable [[API]]. The learning path itself is important, but to stress the important point, here is the code for the final solution of the [[expression problem]]:
		+
		+	<source lang="java" snippet="visitor.clientprovider.v1"/>
		+
		+	[[Visitor]]s written using this style are easily extensible, by adding new expression types as shown in version 2.0:
		+
		+	<source lang="java" snippet="visitor.clientprovider.v2"/>
		+
		+	This is the most flexible solution. It uses form of ''tripple'' dispatch - e.g. the final visit method is defined by the expression type, version of the expression language and implementation of the [[visitor]] interface:
		+
		+	<source lang="java" snippet="visitor.clientprovider.dispatch.v3.l2"/>
		+
		+	This solution to the [[expression problem]] is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]].
		+
		+	[[Category:APIDesignPatterns]]
		+	[[Category:APIDesignPatterns:Evolution]]

JaroslavTulach at 20:06, 17 August 2008

JaroslavTulach — Sun, 17 Aug 2008 20:06:41 GMT

←Older revision		Revision as of 20:06, 17 August 2008
Line 1:		Line 1:
-	~~Food~~ for ~~thought~~.	+	== [[Have You Ever Wondered]]...? ==
		+
		+	Do you wonder whether knowledge of proper design patterns makes you good API designer? Yes and no. Of course knowing regular design patterns simplifies communication, understanding, etc. However there are hidden catches. Not every design pattern belongs among [[APIDesignPatterns]] - it may not be ready for evolution. For example the well known [[wikipedia::Visitor_pattern\|Visitor pattern]] is really not evolvable easily as analysed by [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]].

Apidesign: Replacing page with 'Food for thought.'

Apidesign — Sat, 14 Jun 2008 06:33:34 GMT

Replacing page with 'Food for thought.'

←Older revision		Revision as of 06:33, 14 June 2008
Line 1:		Line 1:
-	~~'''Done: 3bfa995fae68'''~~	+	Food for thought.
-		+
-		+
-	~~I liked this section, too. Practical, example-based ways of applying the concept learned in the book. Awesome.~~	+
-		+
-	~~I'd almost recommend that this and the previous section should be in their own part of the book. "Part IV: Experiences" or something.~~	+
-		+
-	~~Paragraph 2: "in the tool apt" doesn't make sense. If "apt" is the name of the tool, it needs to be set apart in quotes or in typeface.~~	+
-		+
-	~~"traversing hierarchies of heterogeneous data structures" (note the spelling of heterogeneous) is quite a chunk of text. Any way to make that a little less haughty-sounding?~~	+
-		+
-	~~--[[User:Dmkoelle\|Dmkoelle]] 02:47, 23 April 2008 (UTC)~~	+
-		+
-	~~"would keep all kinds of compatibility, see expr, based on generics": what is "expr"? Looks like a link is missing.~~	+
-		+
-	~~Why are most of the classes in the visitor examples static?~~	+
-		+
-	~~In the visitor pattern, it is common~~ for ~~the method in the element classes (<tt>Plus</tt>, etc.) which takes a visitor instance to be named <tt>accept</tt>, not <tt>visit</tt>.~~	+
-		+
-	~~The "Old visitor used on new exceptions" message in the abstract <tt>Visitor</tt> doesn't make sense to me, perhaps "new elements" is what you meant.~~	+
-		+
-	Common Java code conventions advice against underscores in identifiers. Moreover, you talk about "Valid10" and "Visitor70" in the text. Please make this consistent, ideally by removing the underscores.	+
-		+
-	~~"exception subtype" should probably be "element subtype".~~	+
-		+
-	Perhaps I'm just missing something, but we fact that <tt>visitMinus</tt> visits the children elements by default looks wrong to me. The visitor pattern describes the visitor as an interface with no default behavior. The actual behavior is implemented by the visitor implementation. But here, you have made an arbitrary choice for the behavior (what if I want to visit the numbers in postorder?), and worse, only for a part of the tree.	+
-		+
-	~~"the client visitor that just called the method" looks unclear. How about "the <tt>Visitor</tt> which was passed to <tt>Expression.visit</tt>"?~~	+
-		+
-	~~--[[User:AndreiBadea\|AndreiBadea]] 12:44, 23 April 2008 (UTC)~~	+
-		+
-	This is my favorite chapter. You're applying the techniques and advice of your style of api design to a well-known design pattern and coming up with something much better. And you're explaining it in a clear, well-delineated manner. Bravo!	+
-		+
-	Andrei, think of the visitMinus example in a different context, like a validating SAX parser. This is like having a flag that tells the parser whether to quit when it finds an unknown tag, or whether to visit the child elements anyway.	+
-		+
-	~~--[[User:Richunger\|Richunger]] 05:19, 26 April 2008 (UTC)~~	+

Richunger at 05:19, 26 April 2008

Richunger — Sat, 26 Apr 2008 05:19:07 GMT

←Older revision		Revision as of 05:19, 26 April 2008
Line 29:		Line 29:

	--[[User:AndreiBadea\|AndreiBadea]] 12:44, 23 April 2008 (UTC)		--[[User:AndreiBadea\|AndreiBadea]] 12:44, 23 April 2008 (UTC)
		+
		+	This is my favorite chapter. You're applying the techniques and advice of your style of api design to a well-known design pattern and coming up with something much better. And you're explaining it in a clear, well-delineated manner. Bravo!
		+
		+	Andrei, think of the visitMinus example in a different context, like a validating SAX parser. This is like having a flag that tells the parser whether to quit when it finds an unknown tag, or whether to visit the child elements anyway.
		+
		+	--[[User:Richunger\|Richunger]] 05:19, 26 April 2008 (UTC)

JaroslavTulach at 20:55, 25 April 2008

JaroslavTulach — Fri, 25 Apr 2008 20:55:00 GMT

←Older revision		Revision as of 20:55, 25 April 2008
Line 1:		Line 1:
		+	'''Done: 3bfa995fae68'''
		+
		+
	I liked this section, too. Practical, example-based ways of applying the concept learned in the book. Awesome.		I liked this section, too. Practical, example-based ways of applying the concept learned in the book. Awesome.

AndreiBadea at 12:44, 23 April 2008

AndreiBadea — Wed, 23 Apr 2008 12:44:16 GMT

←Older revision		Revision as of 12:44, 23 April 2008
Line 8:		Line 8:

	--[[User:Dmkoelle\|Dmkoelle]] 02:47, 23 April 2008 (UTC)		--[[User:Dmkoelle\|Dmkoelle]] 02:47, 23 April 2008 (UTC)
		+
		+	"would keep all kinds of compatibility, see expr, based on generics": what is "expr"? Looks like a link is missing.
		+
		+	Why are most of the classes in the visitor examples static?
		+
		+	In the visitor pattern, it is common for the method in the element classes (<tt>Plus</tt>, etc.) which takes a visitor instance to be named <tt>accept</tt>, not <tt>visit</tt>.
		+
		+	The "Old visitor used on new exceptions" message in the abstract <tt>Visitor</tt> doesn't make sense to me, perhaps "new elements" is what you meant.
		+
		+	Common Java code conventions advice against underscores in identifiers. Moreover, you talk about "Valid10" and "Visitor70" in the text. Please make this consistent, ideally by removing the underscores.
		+
		+	"exception subtype" should probably be "element subtype".
		+
		+	Perhaps I'm just missing something, but we fact that <tt>visitMinus</tt> visits the children elements by default looks wrong to me. The visitor pattern describes the visitor as an interface with no default behavior. The actual behavior is implemented by the visitor implementation. But here, you have made an arbitrary choice for the behavior (what if I want to visit the numbers in postorder?), and worse, only for a part of the tree.
		+
		+	"the client visitor that just called the method" looks unclear. How about "the <tt>Visitor</tt> which was passed to <tt>Expression.visit</tt>"?
		+
		+	--[[User:AndreiBadea\|AndreiBadea]] 12:44, 23 April 2008 (UTC)

Dmkoelle: New page: I liked this section, too. Practical, example-based ways of applying the concept learned in the book. Awesome. I'd almost recommend that this and the previous section should be in their...

Dmkoelle — Wed, 23 Apr 2008 02:47:02 GMT

New page: I liked this section, too. Practical, example-based ways of applying the concept learned in the book. Awesome. I'd almost recommend that this and the previous section should be in their...

New page

I liked this section, too. Practical, example-based ways of applying the concept learned in the book. Awesome.

I'd almost recommend that this and the previous section should be in their own part of the book. "Part IV: Experiences" or something.

Paragraph 2: "in the tool apt" doesn't make sense. If "apt" is the name of the tool, it needs to be set apart in quotes or in typeface.

"traversing hierarchies of heterogeneous data structures" (note the spelling of heterogeneous) is quite a chunk of text. Any way to make that a little less haughty-sounding?

--[[User:Dmkoelle|Dmkoelle]] 02:47, 23 April 2008 (UTC)