We were told a design pattern is a solution of a problem in a given context.
The metaphor above focuses our thinking on a space of a given problem. But if we extended a view a little more, we would see there is one more thing: tools.
So, a design pattern is a solution of a problem in a given context with given tools usage. And tools are obviously programming languages we use. Observing programming languages evolution (as I remember a great piece of it was given here), we may arrive at the conclustion that design patterns try to solve lacks of programming languages.
From this point of view moving to a next programming language may cause a problem disappears.
So don't try to introduce patterns to solve the problem you faced with. Find a technology where the problem is gone. This is a way I understand the Polyglot Programming movement. I think it is the right direction.
agile (39) anti-patterns (17) architecture (32) books (10) buissness analysis (1) cases (1) code speaks 2u (3) conferences (13) conversation patterns (26) customer collaboration (14) ddd (4) design patterns (15) dialogi (1) dsl (2) effectiveness (19) embedded (1) events (21) gtp (4) info (2) infoq (5) kanban (2) lean (2) master (1) measuring (1) orm (2) pea (2) product humanisation (1) refactoring (13) requirements (7) retrospections (1) retrospective (1) scrum (9) scrumguide (1) sm (1) soft skills (4) software craftsmanship (14) tdd (1) team (20) time management (3) tutorial (1) uml (1) user stories (1) visions (26)