Heap things on a function x DRY

Question

That bold bit taken from here it wasn’t very clear to me:

DRY solves what?

Some may still be thinking that DRY is to reduce typing. Or at least gain maintenance time. It’s even in the latter case, but not because it has less code on its own (though less code always helps something). The reduction in maintenance time is not having to hunt for redundancies, peacefully make a change knowing that everything will remain consistent, without having to fix mistakes that you don’t even imagine will happen when something changes.

DRY requires that any code information be unique. DRY creates an authoritative source of what should be a behavior.

Done correctly increases cohesion and decreases coupling. Done wrong...

DRY helps to have sole responsibility. Trying to stack things together in one function just to avoid repetition only makes SRP worse. That’s why it’s important to distinguish DRY from repeat elimination.

DRY specifically prevents maintenance nightmares. More abstractly it requires the programmer to think about what he’s doing, because he’s putting that code there and can do otherwise for future use. DRY is planning.

Does it have to do, in OOP, with breaking a method that does many things on different objects? Would anyone have an example? (doesn’t need to be OOP)

Answer 1

It’s not about OOP, it’s about modularization. OOP can be a technique to be used for this. Breaking something in various methods is not even something of OOP even, OOP can facilitate because you don’t have to keep passing arguments when calling methods that makes only a part of the task, something that can be seen in more detail in How many parameters a method should have?. It is a fact that you have a unique data structure accessible in one method without you making additional effort encourages you to break the methods into small pieces while maintaining a single responsibility. Nothing prevents you from doing otherwise, but if you have to use parameters to communicate the trend is you prefer to break less (that’s more or less what happens with Git and other distributed Vcses, they end up encouraging you to do more commits with minor changes).

There are things that we write because we have something in mind at the moment, it is not always clear at all, it can have influence of something that had just happened. So I don’t remember exactly what was going on at that moment :) I know what that means in general.

What I think I meant there was less about piling up things and more about repetition. And maybe it was about what I said in the first paragraph above. Maybe some people think that passing data back and forth generates code repeats. I know a lot of people who’d rather make a sausage than have to do that. Eventually to do DRY and follow the SRP you have to repeat something, you have to write some glue code that seems to have done before.

Another case that comes to mind is the use of overload. Some people may find that creating multiple overloads will repeat the header of the function or even parts of the code, and making a single making decisions of what to perform may decrease the repetition, but worsen the SRP, and performance.

In many cases, even if the code gets longer, it may be more readable to create something canonical. Some people find it exaggerated, and may even be in some cases, but there may be interesting expressiveness gains when for example creates a method just to establish a condition and call this method in a if or any other relevant place. The method gives a name to what that is, it gets more SRP and possibly more DRY because whenever you need to know about the state meeting that condition has a method ready for it and you don’t have to hunt to see if you’re not reinventing the wheel, if you have to change somewhere.

You can think of some cases where it’s best to separate a piece of code, even if it’s not used repeatedly elsewhere. DRY may not avoid repetition, but it always makes it more obvious what you’re doing.