aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Patterns lead to over-engineering (?) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Patterns lead to over-engineering (?)" Watch "Patterns lead to over-engineering (?)" New topic
Author

Patterns lead to over-engineering (?)

Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4462
    
    6

Found in the December 2001 issue of Software Development Magazine, the sidebar "Design Patterns Poker" for the coverage of the Software Development East conference:
"...Actually, if you start with the patterns, I find you often over-engineer your system; in that sense, they're better for refactoring." - Joshua Kerievsky

Your opinions / experience?
Junilu


Junilu - [How to Ask Questions] [How to Answer Questions]
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
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>
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4462
    
    6

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
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
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.


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Michael McElwee
Ranch Hand

Joined: Nov 06, 2001
Posts: 30
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


SCJP2<br />IBM Certified Solution Developer<br />MCSD
Jeff Binnig
Greenhorn

Joined: Jul 02, 2001
Posts: 13
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.
------------------

Mostly Oracle, C#, VB, SQL Server, ASP.NET, COM+, JSP, Java, Servlets.
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
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).]
Tiger Scott
Ranch Hand

Joined: Mar 01, 2001
Posts: 223
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
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Tiger Scott
Ranch Hand

Joined: Mar 01, 2001
Posts: 223
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Patterns lead to over-engineering (?)