Difference between revisions of "Publications/verna.10.jucs"
From LRDE
Line 7: | Line 7: | ||
| volume = 16 |
| volume = 16 |
||
| pages = 246 to 271 |
| pages = 246 to 271 |
||
− | | |
+ | | lrdeprojects = Software |
− | | urllrde = 201004-JUCS |
||
| 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. |
| 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. |
||
| lrdekeywords = Software engineering |
| lrdekeywords = Software engineering |
||
Line 21: | Line 20: | ||
volume = 16, |
volume = 16, |
||
pages = <nowiki>{</nowiki>246--271<nowiki>}</nowiki>, |
pages = <nowiki>{</nowiki>246--271<nowiki>}</nowiki>, |
||
− | project = <nowiki>{</nowiki>Software<nowiki>}</nowiki>, |
||
abstract = <nowiki>{</nowiki>While software design patterns are a generally useful |
abstract = <nowiki>{</nowiki>While software design patterns are a generally useful |
||
concept, they are often (and mistakenly) seen as ready-made |
concept, they are often (and mistakenly) seen as ready-made |
Revision as of 12:15, 26 April 2016
- Authors
- Didier Verna
- Journal
- Journal of Universal Computer Science
- Type
- article
- Projects
- Software"Software" is not in the list (Vaucanson, Spot, URBI, Olena, APMC, Tiger, Climb, Speaker ID, Transformers, Bison, ...) of allowed values for the "Related project" property.
- 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}, 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.} }