Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I was talking with my architect about some concerns with a particular approach that may result in very low level of cohesion in a set of classes. However, I couldn't think of the word that represents a low level of cohesion.

I said something along the lines of "Obviously, we want cohesive classes not... uh ... not cohesive classes"

What's the correct word I should have used?

share|improve this question
    
Cohesive things work together, disjoint things work separately. –  Jimmy Hoffa Oct 5 '12 at 22:02
    
I was going to say incohesive, but that doesn't seem to be a real word. –  Mr Lister Oct 6 '12 at 6:28

7 Answers 7

up vote 11 down vote accepted

According to Wikipedia,

Cohesion is an ordinal type of measurement and is usually expressed as “high cohesion” or “low cohesion” when being discussed.

So I think the phrase becomes "Obviously, we want highly cohesive classes, not classes with low cohesion".

share|improve this answer
2  
+1 I've never heard another word used besides cohesion. Using a word that isn't widely understood to be the opposite of cohesion (in software development terms) may only cause confusion. –  David Peterman Oct 6 '12 at 5:09
    
The community has spoken! So I'll take this. –  justnS Oct 12 '12 at 15:36

Personally, I'd probably use "disjointed" to mean the opposite of "cohesive" if you were just looking for a conversational, qualitative description.

share|improve this answer
2  
I think "disjointed" is an opposite of "coupled", not "cohesive". Although the two concepts are correlated, they are not the same. –  dasblinkenlight Oct 5 '12 at 22:04
    
I understand the difference between the metrics, but I'd say disjointed is closer to opposing "cohesive" than "coupled". Disjointed is an antonym for "coherent", which I'd say is closer to "cohesive" than "coupled". Coherence and cohesion both imply rational grouping, whereas coupled just implies proximity. My take, anyway, for what it's worth. (edit - I guess it's also the opposite of "joined" though, obviously, so that maybe puts us back at square one :) ) –  Erik Dietrich Oct 5 '12 at 22:11
3  
Yeah, I am almost tempted to post this question to the English Stack Exchange site, and see what they have to say :) –  dasblinkenlight Oct 5 '12 at 22:15

If you don't like "disjointed", I'd suggest "incoherent". The exact antonym, "coherent", seems similar to the meaning of "cohesive" in the context of systems architecture.

I also like "incoherent" because it suggests a lack of coordination among disparate parts.

share|improve this answer

However, I couldn't think of the word that represents a low level of cohesion.

People use terms like 'low-cohesion' or 'high-cohesion', although definition of either is arguable. Technically cohesion can be seen as (Wikipedia),

  • Coincidental cohesion (worst) - Coincidental cohesion is when parts of a module are grouped arbitrarily; the only relationship between the parts is that they have been grouped together (e.g. a “Utilities” class).

  • Logical cohesion: Logical cohesion is when parts of a module are grouped because they logically are categorized to do the same thing, even if they are different by nature (e.g. grouping all mouse and keyboard input handling routines).

  • Temporal cohesion: Temporal cohesion is when parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution (e.g. a function which is called after catching an exception which closes open files, creates an error log, and notifies the user).

  • Procedural cohesion: Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution (e.g. a function which checks file permissions and then opens the file).

  • Communicational cohesion: Communicational cohesion is when parts of a module are grouped because they operate on the same data (e.g. a module which operates on the same record of information).

  • Sequential cohesion: Sequential cohesion is when parts of a module are grouped because the output from one part is the input to another part like an assembly line (e.g. a function which reads data from a file and processes the data).

  • Functional cohesion (best): Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module (e.g. tokenizing a string of XML).

What's the opposite of cohesive?

I said something along the lines of "Obviously, we want cohesive classes not... uh ... not cohesive classes"

No opposite, i.e., no 'non-cohesive' or 'not-cohesive' etc.

share|improve this answer

"Refractory" means

  1. Obstinately resistant to authority or control.
  2. Difficult to melt or work; resistant to heat (w.r.t. metal working)

If your classes are refractory, then they don't work smoothly together, and it is hard for maintainers to go in and make changes that span many classes.

This seems to be a decent antonym for the sense of "cohesive" that you're using : joined together in a well-functioning and orderly manner.

share|improve this answer

Robert C. Martin brings up the term "fragile design" in connection with SRP: The Single Responsibility Principle:

If a class has more then one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

He defines fragility as:

Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way.

As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved.

Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost.

(Design Principles and Design Patterns)

The term "fragile" as a decription of a class occurs also in the fragile base class problem.

share|improve this answer

Google repulsive and you get: repellent (among others).

Since each "class" appears to have an equal weighting relative to the others, a mutual or "peer energy" would be in order. "repellent classes" seems to roll off the tongue fairly well.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.