aspose file tools*
The moose likes Agile and Other Processes and the fly likes Clean Code: Don't Repeat Yourself? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Clean Code: Don Watch "Clean Code: Don New topic
Author

Clean Code: Don't Repeat Yourself?

Bart Kummel
author
Ranch Hand

Joined: Nov 30, 2007
Posts: 81
Hi Robert C. Martin,

I see you have a section on "Don't Repeat Yourself" in your book. I think this is a very useful rule of thumb. But there is a danger in it. The danger is that you make a generic solution for everything. Those generic solutions can get too generic and very complicated. How do you find a balance between not repeating yourself and not making everythin generic?

Best regards,
Bart Kummel


SCJP 1.4 | SCJD 1.6 | Visit my website | Author of the book Apache MyFaces 1.2 Web Application Development
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Can you give an example for a solution that is complex because it's too generic, and which was implemented to reduce duplication? Thanks!


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
Bart Kummel
author
Ranch Hand

Joined: Nov 30, 2007
Posts: 81
I don't have a concrete example at hand now, but I remember a case where someone made an object model where everything in the end inherited from a class named "Item". Of course this is an obvious design flaw, but it was in production at a client's office. It became a real nightmare when we had to serialize objects, we ended up with a huge amount of nearly empty serialized objects...
Paul Croarkin
Ranch Hand

Joined: Sep 30, 2004
Posts: 106
I don't follow how repeating yourself would have made this a more manageable project. I've found that cut-and-paste coding (i.e. repeating yourself) almost always leads to maintenance nightmares.


Thanks,<br /> <br />Paul Croarkin<br />SCEA 5, SCWCD, SCJP
Bart Kummel
author
Ranch Hand

Joined: Nov 30, 2007
Posts: 81
The point is that the "Item" class was introduced as a way to avoid repeating code. So this was an example of how a wrong approach of preventing duplicate code could cause another problem...
J. Nuno
Greenhorn

Joined: Jul 11, 2008
Posts: 13
Hi,

I share the same doubt as Bart, and I'll try to give a concrete example:

Imagine you're building a master-detail in which the master is a list containing two different entity types which in the begining of the project had almost equal detail forms, one detail was editable but the other wasn't, but the detail form design was the same.

How should one design the GUI in this situation, one class which you would pass a flag editable or since the entity type is different and you are affraid of a future change you prefer to create two different detail forms, breaking the DRY principle?

Thank you!
Paul Croarkin
Ranch Hand

Joined: Sep 30, 2004
Posts: 106
You should never be afraid of future changes or refactoring. Adding an editable flag on the detail page does not seem like a big deal to me and it does not violate DRY.
Paul Croarkin
Ranch Hand

Joined: Sep 30, 2004
Posts: 106
Bart,

Yes, overuse of inheritance can be a bad design, but I don't see how that excuses not using DRY. Maybe interfaces should have been used instead and / or composition.

Also, I do not see how violating DRY would help you with your serialization issue. It sounds like the classes in question did not properly implement Serializable.

If I ran across an issue like that, the first thing I would do is write some tests to serialize and de-serialize the objects. Tests would also be constructed to make sure that the existing production functionality worked. After that, re-factoring.
[ September 23, 2008: Message edited by: Paul Croarkin ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Bart Kummel:
The point is that the "Item" class was introduced as a way to avoid repeating code. So this was an example of how a wrong approach of preventing duplicate code could cause another problem...


Without knowing more, this seems to be more a misuse of inheritance than a misuse of avoiding duplication. I'd assume that there would have been a better way to avoid that duplication that wouldn't have had those problems.

There are kinds of duplication that are very hard to get rid of, though - often due to lack of language features.

Try to get rid of duplicating



for example. (It's possible using reflection. But that's not pretty...)
Bart Kummel
author
Ranch Hand

Joined: Nov 30, 2007
Posts: 81
Don't get me wrong. I'm not looking for excuses to break with DRY. To the contrary, DRY is one of the most important principles in programming for me. But I'm not only a programmer, but also a coach. And sometimes I see code from people I coach that solves a DRY problem in a very wrong way, like I illustrated. What I'm interested in, is are ways to DRY in the right manner.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
In my experience, DRY is almost always doable and preferable. It's not always easy to do it right, though.
Bart Kummel
author
Ranch Hand

Joined: Nov 30, 2007
Posts: 81
@Ilja: that's exactly my point. I hope the book will give some guidelines on how to DRY right...
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
On very rare occasion, I've seen where removing duplication made a system a real bear to understand and maintain.

The larger problem is when programmers try to predict duplication, and prematurely introduce abstractions because they think they might someday need them. That introduces an interrim cost for something that might never come.

I'd say that in the vast majority of cases, we have far too much duplication, so I usually view the objection to removing duplication as more philosophical or academic. In practice, we have a lot of work to do before we start worrying about the very rare case where a bit of duplication is preferable.

Jeff


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Robert Martin
Author
Ranch Hand

Joined: Jul 02, 2003
Posts: 76
Originally posted by Bart Kummel:
Hi Robert C. Martin,

I see you have a section on "Don't Repeat Yourself" in your book. I think this is a very useful rule of thumb. But there is a danger in it. The danger is that you make a generic solution for everything. Those generic solutions can get too generic and very complicated. How do you find a balance between not repeating yourself and not making everythin generic?

Best regards,
Bart Kummel


This is going to sound flippant. The solution is to keep the generic solution simple.

There is s difference between generic and complex. Generic solutions do not need to be complex. Indeed, in most cases generic solutions are simpler than specific solutions. F=Gm1m2/r^2 is a lot simpler than Ptolemy's model of the solar system -- and it is _much_ more generic.

There is also a big difference between DRY code and generic code. The lack of duplication does not mean that the code is highly generic. It just means that you've eliminated the duplication.


---<br />Uncle Bob.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Clean Code: Don't Repeat Yourself?
 
Similar Threads
Code Assist doesnt work for JSP in Eclipse
2 classloaders 1 JVM
Problem with RMIC
WA #1.....word association
confirm of h:commandLink