

Cohesion and Coupling in Large Projects - abhirakshit
http://blog.architexa.com/2010/06/cohesion-and-coupling-in-large-projects/

======
jamesbritt
"[F]ollowing some simple rules can help. Steps like providing intuitive names
to methods and classes, moving closely related functionalities to a common
class, or moving unrelated stuff out into appropriate classes, goes a long way
towards helping to maintain a healthy code-base"

Well, you know, duh.

A reason there are such problems with code is not that developers don't quite
know what they should be doing (though that is sometimes the case), but that
many things that are easy to state in words are far from easy to do in
practice.

What, exactly, is "intuitive"? Intuitive to whom? How exactly do you decide
when things are closely related? By what measure?

~~~
abhirakshit
Hey James I understand its not always easy to implement the best practices on
real application and I have amply mentioned that in the post. What I am
implying is that if we keep these things in mind and at least make an
conscious effort to follow them it does really help. When I mean intuitive I
mean something which will give a decent idea what that method or class is
supposed to do. Also I am sure you must have some idea of how you can group
code modules your project. Moreover looking at types of cohesion can give a
decent idea of what elements can be grouped together.

~~~
jamesbritt
"When I mean intuitive I mean something which will give a decent idea what
that method or class is supposed to do."

OK, but that's fraught with peril. You first have to know what the method or
class is supposed to do now and in the future, and code has a tendency to
mutate out from under you. The trouble is that the change can be slow and
subtle, and then one day it strikes you (or, more likely, another developer)
that the class has become kind of gnarly. The absence of fairly clear-cut
guidelines means you're winging it all along.

"Also I am sure you must have some idea of how you can group code modules your
project."

Things go together until the don't. Over time the behavior some code creeps
over to some new realm, and one day you find the code a bit tangled. I'm
wondering to what extent there are, or can be, applicable rules to alert you
before your gut kicks in.

"Moreover looking at types of cohesion can give a decent idea of what elements
can be grouped together."

True, understanding the different ways things can be associated can help. But
there's quite a bit of subjectivity. Maybe that's unavoidable, but the article
(and perhaps most similar articles) don't go far enough in discussion
concrete, repeatable practices to deal with this, or discussing why this may
not even be possible.

It is very much like design articles that advocate being "simple" without
offering a compelling definition of simple or how you actually achieve it.

But that's the hard part.

(Also, I have to wonder to what extent this is more a problem with OOP and
less with FP. )

~~~
abhirakshit
I know that methods and classes mutate and their functionalities change over
time. And the day it 'strikes you :)' that it has become gnarly it is time to
refactor. How you proceed to do that is a different issue.

Personally I haven't come across a set of guidelines having more in-depth
solution than what I have tried to mentioned here which works in all cases. It
is a question quite dependent on the type of project you are working on. I
think the best person who can properly direct you is the Architect or somebody
with experience who knows the project thoroughly.

~~~
jamesbritt
In wondering about the funky nature of this problem, it occurred to me that it
is an exercise in taxonomy.

    
    
        "There are only two hard problems in Computer Science: 
         cache invalidation and naming things."
         --  Phil Karlton
    
    

Coupling and coherence are essentially about naming things, about identifying
the core nature of something.

