Difference between revisions of "Publications/verna.10.jucs"

From LRDE

Line 12: Line 12:
 
| type = article
 
| type = article
 
| id = verna.10.jucs
 
| id = verna.10.jucs
  +
| identifier = doi:10.3217/jucs-016-02-0246
 
| bibtex =
 
| bibtex =
 
@Article<nowiki>{</nowiki> verna.10.jucs,
 
@Article<nowiki>{</nowiki> verna.10.jucs,
Line 17: Line 18:
 
title = <nowiki>{</nowiki>Revisiting the Visitor: the Just Do It Pattern<nowiki>}</nowiki>,
 
title = <nowiki>{</nowiki>Revisiting the Visitor: the Just Do It Pattern<nowiki>}</nowiki>,
 
journal = <nowiki>{</nowiki>Journal of Universal Computer Science<nowiki>}</nowiki>,
 
journal = <nowiki>{</nowiki>Journal of Universal Computer Science<nowiki>}</nowiki>,
  +
doi = <nowiki>{</nowiki>10.3217/jucs-016-02-0246<nowiki>}</nowiki>,
 
year = 2010,
 
year = 2010,
 
volume = 16,
 
volume = 16,

Revision as of 15:51, 18 June 2019

Abstract

While software design patterns are a generally useful concept, they are often (and mistakenly) seen as ready-made universal recipes for solving common problems. In a waythe danger is that programmers stop thinking about their actual problem, and start looking for pre-cooked solutions in some design pattern book instead. What people usually forget about design patterns is that the underlying programming language plays a major role in the exact shape such or such pattern will have on the surface. The purpose of this paper is twofold: we show why design pattern expression is intimately linked to the expressiveness of the programming language in use, and we also demonstrate how a blind application of them can in fact lead to very poorly designed code.


Bibtex (lrde.bib)

@Article{	  verna.10.jucs,
  author	= {Didier Verna},
  title		= {Revisiting the Visitor: the Just Do It Pattern},
  journal	= {Journal of Universal Computer Science},
  doi		= {10.3217/jucs-016-02-0246},
  year		= 2010,
  volume	= 16,
  pages		= {246--271},
  abstract	= {While software design patterns are a generally useful
		  concept, they are often (and mistakenly) seen as ready-made
		  universal recipes for solving common problems. In a way,
		  the danger is that programmers stop thinking about their
		  actual problem, and start looking for pre-cooked solutions
		  in some design pattern book instead. What people usually
		  forget about design patterns is that the underlying
		  programming language plays a major role in the exact shape
		  such or such pattern will have on the surface. The purpose
		  of this paper is twofold: we show why design pattern
		  expression is intimately linked to the expressiveness of
		  the programming language in use, and we also demonstrate
		  how a blind application of them can in fact lead to very
		  poorly designed code.}
}