I have often noticed that applying DRY to two things which are similar, but not the same, becomes a painful maintenance experience. Trying to maintain a unified abstraction between the two will often be harder due to coupling than duplication will. There is also the idea is that often we refactor similar code into a single abstraction for DRY purposes too early, before the abstraction becomes clear. Then we fight with an ill-fitting abstraction as we maintain the code. I like how Sandi Metz put it: "Duplication is better than the wrong abstraction."
I tend to use DRY only when it is obviously applicable. E.g. I have the exact same function in two places. But if there are some variances, I go ahead with duplication until it becomes clear that they should stay different or that they are the same.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have often noticed that applying DRY to two things which are similar, but not the same, becomes a painful maintenance experience. Trying to maintain a unified abstraction between the two will often be harder due to coupling than duplication will. There is also the idea is that often we refactor similar code into a single abstraction for DRY purposes too early, before the abstraction becomes clear. Then we fight with an ill-fitting abstraction as we maintain the code. I like how Sandi Metz put it: "Duplication is better than the wrong abstraction."
I tend to use DRY only when it is obviously applicable. E.g. I have the exact same function in two places. But if there are some variances, I go ahead with duplication until it becomes clear that they should stay different or that they are the same.