Coherent, in principle

April 3 2012

intrigued by a recent thread on the Italian Extreme-Programming mailing list (sorry, registered members only), I just remembered I collected thoughts about design principles, that I didn’t shared yet.

basically, I tried to map the “overlapping” between the 5 SOLID principles and the 5 GRASP “primary” principles. in my view, they address four basic topics:

  • flexibility (aka software evolution)
  • encapsulation
  • coupling
  • cohesion

sure, that’s nothing new, and they are all related each other. it’s just a quick reminder: “what’s DIP all about? coupling”, “what about Creator? encapsulation!”.

regarding (functional) cohesion, Larman’s book provides a broader context for “measuring” how much an object is cohesive: number of functional areas, number of responsibilities.

sure, this could sound too “academic”. and in fact I can’t keep from smiling and thinking about Dead Poets Society, quoting the “PIG” graph:

“If the poem’s score for perfection is plotted along the horizontal of a graph, and its importance is plotted on the vertical, then calculating the total area of the poem yields the measure of its greatness.”

anyway, High Cohesion principle suggests designing objects with “few responsibilities, in one single functional area”. SRP goes further, saying an object should have a single responsibility. but this doesn’t mean having “one-(public)-method” objects: High Cohesion clearly doesn’t mandate this, nor SRP.

object services (aka published interface) should be narrowed around its single responsibility. Bob Martin says objects with “one reason to change”. so, having only one public method is an option, but not a requirement, as long as published interface consists of few methods, all belonging to the same functional area, all evolving together.

yep, this is hard to achieve. while “few methods” and “one functional area” are easier metrics, something you could understand looking at the code at any given moment, “evolving together” implies monitoring the future, tracking code changes, like commits in a revision control system. given a class, had all its changes a common reason?

I think I’m watching the Dead Poets Society movie again, tonight!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: