std.fileformats?

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Jan 7 19:26:13 UTC 2020


On Tue, Jan 07, 2020 at 12:17:57PM +0000, berni44 via Digitalmars-d wrote:
> On Tuesday, 7 January 2020 at 00:10:08 UTC, H. S. Teoh wrote:
> > After so many decades of academia and industry alike trumpeting code
> > reuse, I'm starting to become skeptical that perhaps King Code Reuse
> > has invisible clothes.
[...]
> Years ago I came to the same conclusion but in a completely different
> area: I was programming generators for sudoku puzzles and it's
> variants. This looks like being ideal for OOP, because all those
> variations are quit similar, but it proved not to be.

Yeah, OOP is another of those things that IMNSHO has been overhyped far
beyond its actual scope of usefulness. It *does* have its uses, that's
undeniable, but only to certain classes (har har) of programming
problems. In writing GUI components, for example, it seems to work
really well.  Trying to shoehorn *every* programming problem into an OO
model, however, to me is a code smell.

(Ironically, modern OO design advice is to avoid inheritance and embrace
composition, which to me is a sign that polymorphism via inheritance,
one of the foundational features of OOP, isn't as widely applicable as
it's hyped to be.)


> The puzzles, the program produced, where not really good. And the
> reason was, that every variation needs it's own optimization for good
> results and that was almost impossible with all those code sharing.
> Eventually I rewrote everything with a single program for every
> variation. That worked much better, although it was code repetition
> over and over again.

Mind you, I'm not against code reuse via refactoring per se. Too much
code repetition is also a code smell... but refactoring and generalizing
to the point of obsession is a sign that it has gone off the deep end.

Sometimes, it's just not worth the trouble, and the technical debt, to
factor out the common code of two (or more) similar pieces of code.
They may be similar but differ in complex ways that cannot be easily
captured via a simple abstraction, and if you try to forcefully push the
refactoring through anyway, you usually end up with a completely
disproportionately more complex architecture that suffers from obvious
symptoms of premature (or over-) generalization and over-engineering.
The result usually is an order of magnitude more difficult to maintain,
disproportionately harder to understand, and contains disproportionately
more LOC.  In such cases, the best solution may actually be copy-n-paste
+ modify. The code may well turn out to be simpler and more maintainable
that way!


T

-- 
Why do conspiracy theories always come from the same people??


More information about the Digitalmars-d mailing list