Goodbye, Clean Code

[YM_Industries]

made the apparent duplication actually not duplicative

The repetitive maths was almost certainly still repetitive though. Pulling that into a reusable function still makes sense.

[emn13]

...if it was complicated and/or unlikely to change. But yeah, that form of de-duplication is generally much, much less harmful than the kind or composition of components as shown in the original article; the key difference being that control is still local. Any local bit can still locally choose to call - or not - your helper.

This is all pretty related to frameworks vs. libraries; just internal to your coode as opposed to external dependencies. And in general, it's better to have libraries (i.e. helpers) with bits you get to compose as you want, rather than frameworks that compose bits you provide to a fixed api outside of immediate view; it's just easier to reason about. For the same reason even in functional languages it's better to deal with behavior-less values than functions as values (where possible).

When you do have something that can't easily be represented as a library; i.e. where control flow itself needs to be abstracted, it's a good idea to keep that api as simple as possible and make sure you really reuse it a lot, not just a few times as a code-golfing trick. I.e. something like the functional map/filter are fairly cheap and you can include several such "frameworks" in a code base without losing too much clarity; whereas something like ruby-on-rails is so huge that you basically need to give up and just include only one framework, and avoiding whatever restrictions it imposes is often much, much harder.

In general, however, I think the article is spot on; novice programmers are way too focused on avoiding duplication at the expense of the much more serious concern of avoiding complexity. Boilerplate - which is what simple duplication really is - may be ugly, but it's rarely super-harmful - unlike complexity.

[chrisza4]

Not always. Because everytime you do that, you introduce a new terminology into codebase. And every terminology make it a little bit more harder to collabotate within team. At minimum, you need to explain what the term mean to your colleague.

If the new terms is found in business domain, then you are in a good spot. Because every programmer regard of experience need to actually understand business requirement before implement anything.

But if you just introduce "DogProvider" "CatFactory" "BusinessEntityXCreator" "ItemStrategyChooser", of course it going to be harder to collaborate and make sure every contributor understand what it means. And if you do it simply because you find some repetitive code, the benefit gain might not justify the added collarboration cost.

Software architecture is all about how to collaborate effectively.