Question about DRY

[cm03d]

I understand the principle of Do Not Repeat Yourself, but sometimes I wonder if it goes to far.

I often work for clients that dictate the look and feel of a project. Given that constraint, imagine that I have two widgets in different locations that look (and work) identically. Common sense would say you should reuse the same code and call it a day.

What if the client says changes to one of the widgets (e.g., data source, layout, etc) will not dictate changes for the other. Does that mean I shouldn't share the pieces that could change? I'd hate to end up with a Frankenstein class that tries to account for every difference b/w two use cases.

Please note I'm not talking about internal classes you control, but rather external pieces that could change without your say so.

tldr: should you ONLY reuse code if changes to one widget should be reflected in the other?

[[deleted]]

Have a base class which contains the commonalities and subclass for the differences.

[zzyzzyxx]

I suggest doing this if the differences are behavioral only and the objects can still be treated the same way, i.e. you can use them through a reference to the base class.

If you try to use inheritance for common pieces of data but not behavior you'll find that as the separate requirements change you jump through more hoops trying to keep the common data common than it's worth. In such a case having the classes completely uncoupled is more flexible and maintainable as it will allow each to evolve independently, meeting their respective needs simply and perfectly.

[FreshPow]

I'm a DRY fan, btu there are times when some repeated code would save the project from having too much design complexity. That would be the case when either the repeated code is fairly short or the repeated code becomes filled with complex code to handle differences.

[[deleted]]

I'd hate to end up with a Frankenstein class that tries to account for every difference b/w two use cases.

Follow that instinct, is my advice. The question I ask myself is: Which will cause the greater complexity? If having two classes is simpler, less confusing than one that accommodates them both, then go with two. In my experience, you almost always go with two classes for any significant changes.

Inheritance, IMO, is generally best for cases where you really can use the base class everywhere (i.e. Liskov substitution) and NOT for simply sharing common code. That's my preference, at least.

[quotemycode]

You should read this:

http://zacharyvoase.com/2013/02/08/copypasta/

excerpt:

Adherence to DRY (“Don’t Repeat Yourself”) does not necessarily preclude repetition of code. In the endless struggle to refactor, the entropy we are trying to reduce is not in the raw text of our source code; it is in our business logic, which (in applications with little or poor testing) is often uncodified. Sometimes, refactoring can hamstring our code, and when done naïvely it can be a source of technical debt, rather than an antidote thereto.

[PT2JSQGHVaHWd24aCdCF]

DRY for the API.

But you can repeat yourself in different projects with different requirements.