Prefer duplication over the wrong abstraction
sandimetz.com
Prefer duplication over the wrong abstraction
1–10 of 101 posts
Re: Prefer duplication over the wrong abstraction
#2And conversely, the right abstraction is preferrable over duplication.
There's almost always chance to stop a little, think/research hard and create something novel, maybe leveraging specific features your language/framework offers.
Re: Prefer duplication over the wrong abstraction
#3How do you know that the abstraction is wrong (and how) if you don't create it?
It seems to me like the article is saying - don't ever make mistakes, they are costly.
Re: Prefer duplication over the wrong abstraction
#4How do you know that the abstraction is wrong (and how) if you don't create it? It seems to me like the article is saying - don't ever make mistakes, they are costly.
Perhaps a better tag line would be "duplication is far cheaper than a bad abstraction".
The take-away from the article for me is if subsequent activity (the changes requiring parameters and if-branches) show it was or has become a bad abstraction, then undo the abstraction and re-introduce the duplication.
Re: Prefer duplication over the wrong abstraction
#5How do you know that the abstraction is wrong (and how) if you don't create it? It seems to me like the article is saying - don't ever make mistakes, they are costly.
I think the point of the article is that, if you aren't totally sure that an abstraction is correct or justified, then it's better to avoid building one in the first place. Not saying to never make mistakes, it's highlighting a particular kind of mistake that people don't always think about, and suggests that you can avoid making this mistake by not being so obsessive with DRY
Re: Prefer duplication over the wrong abstraction
#6I love the thinking and agree with this as much as can be agreed with something general and lacking specific examples or specific situations. It's a nice reminder that there are other options besides modifying a base class to fit only one case's requirements.
I'd call it forking instead of duplication to emphasize that the paths are different, not equal.
When this problem does come up, it's not usually trivial. Often the abstraction doesn't break at the same time the second use is introduced, it breaks much later after the second use is built, making it more difficult to fix.
The much more common problem I've experienced in industry is people making an abstraction with only one use case, anticipating before even having a second use case. It's much easier to discuss and fix if everything you're facing is concrete, and anticipating uses without having them at hand nearly always results in a broken abstraction.
I'd love to see more about how to determine the abstraction is wrong.
> If you find yourself passing parameters and adding conditional paths through shared code, the abstraction is incorrect.
This seems too simplistic. The right answer for this description is often inheritance. What are better ways to identify a broken abstraction?
Re: Prefer duplication over the wrong abstraction
#7And conversely, the right abstraction is preferrable over duplication. There's almost always chance to stop a little, think/research hard and create something novel, maybe leveraging specific features your language/framework offers.
Duplication is fine until it gets out of hand, at which point you'll be able to identify the right abstraction.
Re: Prefer duplication over the wrong abstraction
#8How do you know that the abstraction is wrong (and how) if you don't create it? It seems to me like the article is saying - don't ever make mistakes, they are costly.
Perhaps a better tag line would be "duplication is far cheaper than a bad abstraction". The take-away from the article for me is if subsequent activity (the changes requiring parameters and if-branches) show it was or has become a bad abstraction, then undo the abstraction and re-introduce the duplication.
Then, why not fix the abstraction instead?
Re: Prefer duplication over the wrong abstraction
#9I feel this is good advice. I think the harder problem is getting buy-in from everyone you work with to do this. Often times I take this approach and have to really try to sell it to people reviewing my code because they've bought into this idea of "DRY ever, no matter what".
DRY yourself is useful when 1. You're repeating yourself more than 2 or 3 times and 2. The inputs/outputs and intention of the code are very, very clear. If that's not case, I'm ok with a little copy/paste.
Re: Prefer duplication over the wrong abstraction
#10Earlier quoted context omitted.
Perhaps a better tag line would be "duplication is far cheaper than a bad abstraction". The take-away from the article for me is if subsequent activity (the changes requiring parameters and if-branches) show it was or has become a bad abstraction, then undo the abstraction and re-introduce the duplication.
Then, why not fix the abstraction instead?
Sometimes you don't know what the right abstraction is yet, you only know it's not the one you have.