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
(41)
anti-patterns
(17)
architecture
(33)
books
(10)
buissness analysis
(1)
cases
(1)
code speaks 2u
(3)
communication
(1)
conferences
(13)
consulting
(1)
conversation patterns
(26)
customer collaboration
(14)
ddd
(5)
design patterns
(15)
desing
(1)
dialogi
(1)
dsl
(2)
effectiveness
(19)
embedded
(1)
events
(22)
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
(28)
Generally true... (all generic statements are true;)
ReplyDeleteBut: how to match problem and proper tool?
1. we must know may tools
2. we must be able to classify problems
How to classify problems? Expert has intuition, but (according to Dreyfus model) Competent thinks in patterns. Below Competent we are simply blind:P
Thanks for your comment:)
ReplyDeleteThere's no simple answers. I think we have focused on frameworks for years. We've jumped from Struts to WebWork, to JSF, to Spring MVC, from MyBatis to Hibernate and back:) and so on.
But next framework solved some problems and brought some problems at the same time. This was never-ending story.
Now we (as a Community) better understand what we do than we did years ago. We are able to define problems areas clearer. In a result our approaches are also more precise.
Yes we have to know many tools and we have to classify problems. But it takes time. There's no shortcuts.
Intuition is nothing but ability to chunk context. You start from general solution (@see http://jdn.pl/node/699 :)) and step by step you learn how to definne smaller problems and solve them in their small contexts with your small tools:)
Building "a procedure" of a problem solving for dummies has no sense. It wouldn't be understood. But helping people to become experts is the option.