Hi Junilu, IMO, it doesnot!By saying it does we are actually under mining the use of patterns.After all only when you use patterns, the design of the system would be in accordance to OO principles. If over-engineering is being thought about keeping the time factor in view - i.e. excessive design then perhaps we could ensure that this does not happen by taking care that the requirements and use cases are broken down into manageable components. As I said this is only my opinion.Would like to hear comments from other javaranchers based on their experiences on the same. -- Sandeep
<b>Sandeep</b> <br /> <br /><b>Sun Certified Programmer for Java 2 Platform</b><br /> <br /><b>Oracle Certified Solution Developer - JDeveloper</b><br /><b>-- Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java </b><br /><b>-- Object-Oriented Analysis and Design with UML</b><br /> <br /><b>Oracle Certified Enterprise Developer - Oracle Internet Platform</b><br /><b>-- Enterprise Connectivity with J2EE </b><br /><b>-- Enterprise Development on the Oracle Internet Platform </b>
I don't think that the statement undermines the use of patterns at all. I think that as a developer, it is prudent to know the downside of any technique you attempt to use. If you know what the pitfalls are then you can avoid them and use the technique more effectively. I am inclined to believe what Joshua says about over-engineering. In my experience, programmers (including myself ) tend to go overboard when implementing things they never have before (and sometimes even with things they have done before), especially if they are the types who like things to be done "the right way." This definitely leads to over-engineering in many cases and it takes a lot of discipline, focus, and self-control to follow KISS. Junilu
Heh. Let me go back to an after-dinner conversation that Joshua and I had in San Francisco a couple of months ago. Josh and I were walking back to our hotels after dinner and started talking about patterns horror stories. The one we in particular came to involved the over-use of the Command pattern. We both had the same experience -- when we first saw the Command pattern we thought "WOW! This is it! I ALWAYS want to build systems like this!" Then we tried it. Oh boy. Command is a fine pattern in certain situations. However, whenever you try to do every action in your system as a command you lead to the following: (1) Lots of objects with data but no behavior (2) Commands with HUGE "doThis()" methods (3) BIG, WIDE command hierarchies in the hundreds of classes. What we found is that we had reinvented procedural programming So we stopped using Command everywhere. I still use it sometimes -- for instance when I need "transaction-like" behavior with the ability to "undo" things and the ability to "stack up" commands for later execution, but I don't think it's a panacea anymore. So, what Josh is saying is that you shouldn't say "Let's use all the patterns we can!" Instead, design to solve the problem at hand. The patterns will emerge from the design as you start looking for commonalities between different parts of the system. Hence, his refactoring comments... Kyle ------------------ Kyle Brown, Author of Enterprise Java (tm) Programming with IBM Websphere See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
I think the point is to use patterns where appropriate, not just for the sake of using patterns. The use of the Command design pattern, for example, can be useful in reducing a bunch of if/then processing and can help to break up the code into separate Classes, which would facilitate multiple developers working on the task at the same time. If, on the other hand, you were fairly certain you would always have only a few choices, some if/then processing would probably be simpler and easier to maintain than the code you would come up with implementing the Command design pattern. Just my $0.02
Three U's that design patterns must satisfy: Useful, usable and used. I just taught a OO/UML/Design Patterns class. It was over most of their heads. We used UML Distilled by Martin Fowler, and Design Patterns by Gamma et al. (GoF). Excellent books. ------------------
Originally posted by Kyle Brown: So, what Josh is saying is that you shouldn't say "Let's use all the patterns we can!" Instead, design to solve the problem at hand. The patterns will emerge from the design as you start looking for commonalities between different parts of the system. Hence, his refactoring comments...
That's exactely what the GoF says about design pattern "They reflect untold redesign and recoding as developers have struggled for greater reuse and flexibility in their software". So if you have identify a simpler pattern for Command, feel free to provide us with it .
Use but not abuse. Fortunately, the GoF book is not a strict step-by-step user-guide. Otherwise, what would become of us, developers, if OO Design was simple as this: "In this situation, you must apply this pattern"? Since the design patterns are based on experience, it can be a solution to our design problem but it is not necessarily THE solution. The first time I was told to use a design pattern, I, young and inexperienced, though at the end "What a lost of time!". But then in the next design, I was so happy to identify the same pattern... I also find interesting in Design Patterns in the maintenance field. Design Pattern provides a common language between the different persons implied in the project. It often comes up that the one that develop the first version of a product leaves the company at the end of the mission. The person involved in the extension of the product, even when little familiar with design patterns, feels more comfortable and confident when identifying design pattern in the design it has to improve or extend. W. [This message has been edited by Wilfried LAURENT (edited November 13, 2001).]
Patterns and OO in general have come under scrutiny for not delivering. OO was to deliver reuse: but most systems are not reused at all for all kinds of reasons. So all the elaborate, complex and costly code goes waste. The same with patterns: they lead to complex code- hard to maintain. If patterns are incorrectly used- with the learning curve involved- that is often the case- things get worse. The XP world is pretty much all for simplying programming and suggest that you avoid patterns- Use patterns when you actually need them. $.02 Sanjay
The same with patterns: they lead to complex code- hard to maintain. If patterns are incorrectly used- with the learning curve involved- that is often the case- things get worse.
If something gets used the wrong way, it shouldn't be surprising that things don't get better. But complex software also doesn't get better by not applying desing patterns at all.
The XP world is pretty much all for simplying programming and suggest that you avoid patterns- Use patterns when you actually need them.
XP doesn't suggest to avoid patterns, afaik. Most XPers I know off suggest to *know* design patterns very well, so you are able to see when your code wants to get refactored into a design pattern, so to speak... As one of the main principles of XP is communication, it would simply be silly to ignore such an effective tool.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Mar 01, 2001
I was letting out a popular opinion out there. Just to quote Martin Fowler: "My advice to XP developers (XPers) using patterns would be to learn about patterns, concentrate on when to apply them (not too early), concentrate on how to implement the pattern in its simplest form first, then add complexity later, and don't be afraid to remove a pattern that isn't pulling its weight." Read the complete article: Is Design Dead? http://www.sdmagazine.com/documents/s=732/sdm0104a/ Sanjay