Geeks With Blogs
Madhawa Learns To Blog : C#, Java .net, c#, java,sql, OOAD and more mad memory dumps...
1. When the application being built today will not change, the code accurately captures all requirements, and there are no planned enhancements or features. The application you are building will be the first and last release.

2. Your application’s code requirements are unique. No software engineer has ever built anything like it. The program does not deal with any of these routing issues like object creation and event notification.

3. There is plenty of time to prototype all of your new design ideas. Alternatively, you are so confident of your ideas that they do not require any proof-of-concept testing.

4. Everyone on your team has worked together for twenty or so years. If you ask Bill to try the “thing-a-ma-jig” trick, he knows exactly what to do. The team already processes a common design vocabulary, so you don’t need to learn someone else’s.

Well… I read this in a book called Professional C# Design Patterns Applied. Anyway I can’t agree with all by 100%. What do you think?
Posted on Sunday, June 25, 2006 7:07 PM Best of Old Blog | Back to top

Comments on this post: When should not Design Patterns be used?

# re: When should not Design Patterns be used?
Requesting Gravatar...
Design patterns seem to be the "in thing" now. They have some merit, but I do not agree with the attitude that a lot of people have regarding them.

Most people that I have meet that use design patterns treat them almost religiously. They ask you, "did you use 'something-or-other' pattern.". When you ask them to explain to you what they mean by "pattern 'something-or-other'" they open up a design patterns book and quote from it.

To me, those people lack a clear understand of why they are using patterns.

So to sum it up, use patterns only if you truly understand why you should use them. Do not use them only because someone told you to. Because if you lack insight into the problems nature, then you would be lost to solve it without someone’s assistance.

On the other hand, if you understand the problems cause, and the reasoning for the design pattern then you would be prepared to handle all four of your "reasons not to use design patterns" when the time arose.
Left by Jason Whitehorn on Jun 25, 2006 9:08 PM

# re: When should not Design Patterns be used?
Requesting Gravatar...
Design patterns provide a solution in context - when the context is right use them - otherwise don't. There are many cases where they don't fit for example I would rarerly recommend anyone to use a singleton or I would mostly suggest using Dependency Injection (one patter) over an Abstract Factory (another pattern)
Also When a lot of people that talk about "design patterns" think GoF patterns but there are over 500 patterns (see
Patterns almanac,, Grady booch site etc.)

Left by Arnon Rotem-Gal-Oz on Jun 26, 2006 9:18 AM

# re: When should not Design Patterns be used?
Requesting Gravatar...
I agree to Jason's fact that most of the people have lack of understanding in Design Patterns and how to use that in appropriate places.

Perhaps, I dont agree with those three points mentioned in the book about not using the design patterns. Patterns are meant to improvise the code quality and give less rooms to bug. You can create a versatile software with design patterns.

All software in this world are always needed to be modified because the needs will ever change. You can't say an single software that is still looks like the same since from its first release.

For instance, we develop an application as per the customer's requirement and give it to him. After couple of months, he comes out with a new feature requirements and want it to be implemented in less time span. What we do is modify the existing application's code by applying all those changes and give it to him back. This is the conventional way of all people do the work. But, when it comes to an "patternized" application, you can just create separate classes and methods which could override the existing methods and classes and build a changed one as a separate library. This happens because of all the previous code has been written with proper patterns like factories, faceds etc., I always interested in doing the "patch" in this manner. A very good example is .NET framework is itself, its an amazing job that how the code has been beautifully modified from .NET 1.1 to NET 2.0, otherwise .NET 2.0 couldn't have been supporting the apps. developed with its previous versions.
Left by Vadivel Kumar on Jun 26, 2006 10:00 AM

# re: When should not Design Patterns be used?
Requesting Gravatar...
Thax all you guys for your valuable ideas.

Arnon, I’m also agreeing with you on Dependency injection over some other patterns including factory patterns. I have seen how effective and practical it is and it has saved my valuable time. But I didn’t get what you are thinking on using singleton pattern. Frankly I have instructed couple of my fellow developers to use singleton pattern in their projects (in correct way). If senior architect like you could share your pros and cons about singleton pattern here, it will be really helpful.

Yes Kumar, you are correct. I don’t think we could pinpoint somewhere that we should use design patterns or we shouldn’t use design patterns by 100%. Like all you guys says its all depends on the situation. But I can’t agree with those 4 things in full.
I’m gonna express my thoughts below on those things.

Let’s get first one.
It’s happened to me couple of times that some customers giving us a project to be developed saying this is the only version and there won’t be further modifications. But later they are coming back to us asking for modifications. So I don’t think we can develop such a way although customer says it won’t change. Like always customers are customers. :) May be authors of that book have interacted with different kinda customers.

Second one.
Mmm I can’t say much abt this. I haven’t got much exp. Anyway all projects I have been working had object creations and some projects had event notifications.

Third one.
Very rarely I got plenty of time to do the prototyping. May be I hadn’t got. Although if I got, I always want to consider others ideas and don’t won’t to reinvent the wheel.

Forth one.
Like in second one what I have to tell is I haven’t got 20 years of exp but have abt 3-4. And I don’t know wether I’ll coding after 20 years from now and if I will do in any case I don’t think there will be the same team I’m working with now.

Left by Madhawa Karunaratne on Jun 26, 2006 8:29 PM

# re: When should not Design Patterns be used?
Requesting Gravatar...
All four situations are extremely unlikely situations. Therefore I think the writers of the book are suggesting to USE design patterns most of the time, by giving only these highly unlikely four situations in which not to use them.
Left by Sandu on Jul 04, 2006 2:15 PM

Your comment:
 (will show your gravatar)

Copyright © Madhawa Karunaratne | Powered by: