1. 7

  2. 2

    A colleague of mine recently pointed to…

    From https://blog.codinghorror.com/code-smells/ ….

    Primitive Obsession Don’t use a gaggle of primitive data type variables as a poor man’s substitute for a class. If your data type is sufficiently complex, write a class to represent it.

    Data Class Avoid classes that passively store data. Classes should contain data and methods to operate on that data, too.

    Data Clumps If you always see the same data hanging around together, maybe it belongs together. Consider rolling the related data up into a larger class.

    My comment then was….

    Primitive Obsession - I keep swinging backwards and forwards on this one. I have done a fair bit of Lisp / Scheme / Perl… and in those languages Primitive Obsession is a bit of a virtue.

    Your wondrous object may be wondrous, but if is still Just Another List, every tool that chews on Lists can do useful things with your wondrous object (and in lisp, almost every tool, and there are thousands, chews on lists (and conversely is a list!)).

    If your wondrous object is a wondrous snowflake that only has it’s own methods…. well, everything you want to do with it needs to be carven out of raw code.

    Conversely, especially in Perl, I would in a few lines conjure amazing hashes of lists of lists of hashs….. and was never be able to maintain what I did.

    I’m currently swinging in favour of D’s ranges or Ruby’s mixin ie. If your wondrous object exposes a few standard methods… empty, front and popFront, it’s an input range and all methods that work with input ranges work.

    But the lisper in me still rebels and points out that this presumes I can foresee every possible thing future me may wish to do, and I know how, ahhh, “inventive” future me is. (Hint: In a language where code is data, you can find lots of useful things to do treating code as data.)

    The Perler in me keeps asking if a hundred lines of code really is more maintainable than one (longish) line.

    Currently I’m still holding the “break everything up into classes and methods” line, but I keep getting the itchy feeling in a more expressive language (like D) I would have far fewer classes and methods, but they would be heavily parameterized.

    And now this talk comes along, and says the lisper in me is perfectly correct and the answer is spec.