Clean Code: Don't Repeat Yourself?

[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

[Ilja Preuss]

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

[Bart Kummel]

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]

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.

[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...

[J. Nuno]

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]

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]

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]

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

if (something != null) something.close();

for example. (It's possible using reflection. But that's not pretty...)

[Bart Kummel]

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]

In my experience, DRY is almost always doable and preferable. It's not always easy to do it right, though.

[Bart Kummel]

@Ilja: that's exactly my point. I hope the book will give some guidelines on how to DRY right...

[Jeff Langr]

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

[Robert Martin]

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.