« Alchemy: BitLists Mk2Bikeshedding »

9 comments

  1. § Zeh said on :

    Nice article.

    Some minor issues folowed by fixes:

    “prefer the format year/month/day.”
    “prefer the format day/month/year.”

    “Instead of doing one thing will,”
    “Instead of doing one thing well,”

  2. § Paul Watt®   said on :

    Thank for the compliment Larry.

    Someone has to count, and I’m glad you took the time to correct me.

  3. § Larry Constantine said on :
    4 stars

    Damn clever presentation! Actually the terms coupling and cohesion predate the 1974 IBM Systems Journal article (Stevens, Myers, and Constantine). They were first used and described in a more obscure paper by me in the 1968 National Symposium on Modular Programming. But who’s counting.

    Great job!

    –Larry Constantine (pen name, Lior Samson, author of Flight Track)

  4. § Paul Watt®   said on :

    @Jamie, thanks for pointing that out.

    @rightfold, I definitely agree. I think that public inheritance is overused mostly because it is misused. I also agree about templates.

    One of the main points that I wanted to convey, is that devs may be trying too hard to reuse code by inheritance, when composition is all that is needed. Not even features like templates have to be employed to gain the benefits.

  5. § rightfold said on :
    4 stars

    Nice post, although I think in languages that have good alternatives to inheritance, those may be preferred to achieve substitutability. For example, in C++ you would often use templates and concepts instead of inheritance.

  6. § Jamie Thomson   said on :

    Typo I think. 3rd paragraph:
    “Tight coupling increases the probability that a component can be reused in more places, by limiting its capabilities to small well-defined tasks. For those of you keeping score at home, high cohesion is the realization of the S, Single Responsibility, in SOLID object-oriented design.”

    That should begin “Tight *cohesion* increases the probability that a component can be reused in more places” should it not?

  7. § Paul Watt®   said on :

    Thanks for the compliments.

    This entry is based on a presentation I gave to colleagues at work for a “Lunch & Learn” session.

    With my increased interest in unit-testing and generic-programming over the last 7 or so years I noticed that all of the classes and code that I reuse, as well as the C++ Standard Library are small concise objects.

    I like metaphors, although I know they don’t immediately register for everyone. The Legos seemed like such a natural visual representation of an interface and how each of the different types of pieces interact.

    Then add in the wisdom I have picked up from reading Meyers, Sutter, Andrescu, and Stroustrup…

    Well, thanks again.

  8. § Ernie Cordell   said on :
    5 stars

    Love your analysis and your example: So many have tried this and have failed to elucidate. Grouping the pieces by characteristic does clarify the use of the pieces and the case for reuse (and abstinence).

  9. § fenbf said on :
    5 stars

    Great article! I love the use of Lego bricks to illustrate the problem ;)

    About ugly code: unfortunately code abuse are occurring quite often and after several months/years all you have to do is to write a new code from scratch. Scarry…


Form is loading...

Contact / Help. ©2017 by Paul Watt; Charon adapted from work by daroz. blog software / web hosting / monetizing.
Design & icons by N.Design Studio. Skin by Tender Feelings / Evo Factory.