Difference between revisions of "Publications/verna.10.jucs"
From LRDE
Line 34: | Line 34: | ||
the programming language in use, and we also demonstrate |
the programming language in use, and we also demonstrate |
||
how a blind application of them can in fact lead to very |
how a blind application of them can in fact lead to very |
||
− | poorly designed code.<nowiki>}</nowiki> |
+ | poorly designed code.<nowiki>}</nowiki> |
− | lrdekeywords = <nowiki>{</nowiki>Software engineering<nowiki>}</nowiki> |
||
<nowiki>}</nowiki> |
<nowiki>}</nowiki> |
||
Revision as of 18:22, 4 November 2013
- Authors
- Didier Verna
- Journal
- Journal of Universal Computer Science
- Type
- article
- Keywords
- Software engineering
- Date
- 2010-01-01
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}, year = 2010, volume = 16, pages = {246--271}, project = {Software}, 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.} }