• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

A word of caution to new pattern users

 
Author
Posts: 6049
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I highly recommend reading the brief article "Rules Are for Fools, Patterns Are for Cool Fools." by Mahesh Dodani in JOOP Oct 1999, p 21. It talks about the Golden Hammer Anti-Pattern applied to patterns. Namely, some developers (myself included) when they first learn patterns, end up overusing them--of course, many young developers do this with lots of tools, notjust patterns.
--Mark
 
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Mark Herschberg:
I highly recommend reading the brief article "Rules Are for Fools, Patterns Are for Cool Fools." by Mahesh Dodani in JOOP Oct 1999, p 21. It talks about the Golden Hammer Anti-Pattern applied to patterns. Namely, some developers (myself included) when they first learn patterns, end up overusing them--of course, many young developers do this with lots of tools, notjust patterns.
--Mark


Check this link...
 
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,
I just went over this article briefly. ... IMO: Honestly speaking it makes very little sense to me. Judging by the title, the author is trying to proof that "overuse" of patterns is a bad thing, but nothing in the article seems to proofs that hypothesis, � and what is "overuse" after all? Mr.Dodani goes on telling us a story with no moral, instead he is offering a set of question that explains nothing. I do agree that improper (in places where they simple make no sense, but again that is a truism) application of patterns will use to "bad" code (perhaps overly complicated, difficult to integrate etc.). Could somebody help me with understanding this issue?
[This message has been edited by Michal Harezlak (edited October 02, 2001).]
 
Mark Herschberg
Author
Posts: 6049
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"When you have a hammer, every problem looks like a nail."
Remember when you got a pail and shovel as a little kid? And you went to the beach and started digging in the sand. The next day, you weren't at the beach, you were home. So you started digging in the back yard, probably in your mom's flower garden. Digging was such fun! And when it was raining, you'd take you shovel and "dig" the puddles. And at dinner, you tried using your shovel on the pile of peas on your plate, until mom told you not to play with your food?
The point is patterns are a powerful tool. As intelligent people, we programmers like and appreciate powerful tools. Sometimes we get overzealous, and use them too much. That's all the article says.
And don't take it so literally, I believe it was written at least somewhat, if not totally, toung-in-cheek. Certainly, it's not meant to be a formal proof of misuse of patterns.
--Mark

Dilbert: "Stupidity is like nuclear power. It can be used for both good and evil."
Wally: "And you don't want to get any on you."
 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think this article serves a good warning - don't use anything just for the sake of using it. However, if I take a hammer and try to use it's nail prys (the part you use to pull out nails) as a screwdriver and then say - "aw, hammers are useless" I think my comment says more about me than about the hammer. I think the same is true for the article. Design patterns have been misapplied a lot because people think they are patterns in DESIGN. Sounds reasonable, since they are called DESIGN patterns. However, if you go back to their roots, you'll discover that patterns live in analysis, design, implementation even test. Our "addict" was using design patterns at the implementation level - hence their mis-use.
There are simple answers to his question:
"How do I know when a pattern is really applicable and will have the needed impact on the application? How do I know that the application of the pattern has made the application more reusable? Will the application become "better" after the patterns are applied? How do I define "better" and determine that the application has become "better"? "
If your solution is more cohesive, more loosely coupled, more easily modifiable, easier to understand, then it is better. If it is not, it is not better.

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book
 
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


If your solution is more cohesive, more loosely coupled, more easily modifiable, easier to understand, then it is better. If it is not, it is not better.


Also another thing I need to point out. Use common sense. Does it make sense to use a factory to create database connection? sure does. Does it make sense to use a factory to create a string object? probably not. That's what the article tried to point out, use common sense. You cannot abuse patterns if you use them with common sense.
Yet another thing. Stick to requirements. I see many project failing to meet deadlines because programmers strive for reuse and object orientation where it is not applicable. Even today, knowing OOAD there is still a place for procedural decomposition to solve some problems. I'm getting out of topic here. sorry.
 
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Alan Shalloway:

...
If your solution is more cohesive, more loosely coupled, more easily modifiable, easier to understand, then it is better. If it is not, it is not better.
...


Alan, I agree with you.
High cohesion, Loose coupling ... are all like basic building blocks which can be combined in various ways to achieve high-level design patterns like the GoF or J2EE patterns. This is exactly what Craig Larman mentions in his classic "Applying UML and Patterns". I actually found the section on GRASP Patterns (based on simple principles such as coupling, cohesion...) in his book a must-read.
If one understands the very basic principles, such as the GRASP, then there is little need to "memorize" other patterns such as the GoF. They should flow automatically or appear through refactoring.
I especially found the GRASP patterns useful because they keep the cluttered vocabulary (the very thing Design Patterns are credited to have facilitated) away. I found there are synonyms of the basic GRASP concepts in different group's patterns such as: Facade=Controller, Wrapper=Decorator, Value Object=Proxy... I am waiting to see more synonyms once the .NET patterns come out
Sanjeev
 
Alan Shalloway
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Sanjeev Arya:

If one understands the very basic principles, such as the GRASP, then there is little need to "memorize" other patterns such as the GoF. They should flow automatically or appear through refactoring.
Sanjeev


I totally agree with this. I think learning basic principles is not emphasized enough and is the approach of our book. I believe this is just as important in managing projects as well. All too often people lean on heavyweight or middleweight processes to guide them and forget that they still have to think.

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book
 
Michal Harezlak
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for all the input. I guess all the comments shade more light on the problem then the original article.
 
Michal Harezlak
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Sanjeev Arya:
I found there are synonyms of the basic GRASP concepts in different group's patterns such as: Facade=Controller, Wrapper=Decorator, Value Object=Proxy...


Sanjeev,
Off topic: I am not sure if you right here, you can find similarities but they are not exactly same things. Check your sources and let me know if you want to continue about it.
Best regards.
 
Sanjeev Arya
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Michal Harezlak:
Sanjeev,
Off topic: I am not sure if you right here, you can find similarities but they are not exactly same things. Check your sources and let me know if you want to continue about it.
Best regards.


Mike,
I did not have an "equivalent" or "approximately equal" symbol on this keyboard I am sure you get the drift when I mention those "similar" patterns. Of course, I have missed many many more patterns which have great great overlap.
Sanjeev
 
Michal Harezlak
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sanjeev:
Understood, I have seen people use: ~=.
Regards.
 
Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic