Weblogs Forum - Coupling is not neccessarily a bad thing!

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Coupling is not neccessarily a bad thing!

35 replies on 3 pages. Most recent reply: May 5, 2005 8:49 PM by Greg Jorgensen

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 35 replies on 3 pages [ « | 1 2 3 | » ]

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Coupling is not neccessarily a bad thing!

Posted: May 3, 2005 12:50 AM

> So for all and intents and purposes then we are all on the
> same page.

I'm afraid I don't think we are. The consensus (as I interpret it) seems to be that coupling is indeed a 'bad thing'. Sometimes it may be unavoidable but that doesn't stop it being 'bad'.

Vince.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Coupling is not neccessarily a bad thing!

Posted: May 3, 2005 3:20 AM

I've been moving into my new house all day, so I didn't get to reply, but that's a good thing, since both Neeraj and Vincent have rejoined more eloquently than I would have.

Additionally, since the in this particular case the discussion of coupling originated with the example of inheritance, I think there is some value in wrapping it up in that context before hollering "rutabaga!"

Maybe Christopher or someone else will offer another example that better demonstrates why coupling is not neccessarily a bad thing? One that doesn't use inheritance might unmuddy the waters a bit...

For example, I can imagine some cases where you might want some coupling in order to get the absolute best possible performance. I imagine the top chess algorithms have more coupling between subsystems (eg. between the move chooser and the position evaluator) than we'd ordinarily consider "good" -- these guys are likely more concerned about blazing performance than modularity.

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: Coupling is not neccessarily a bad thing!

Posted: May 3, 2005 3:32 AM

That's exactly my position.

In my experience, avoidance of coupling has been a stand-out characteristic of successful projects, i.e. ones that have been able to evolve with (the inevitable) changing requirements.

Kristian Dupont

Posts: 22
Nickname: chryler
Registered: Dec, 2003

Re: Coupling is not neccessarily a bad thing!

Posted: May 3, 2005 3:49 AM

Another point which I think is worth mentioning is that loosely coupled code is often more agile. Designing a class hierarchy seems very up-front to me. If I consider some problem from an old-fashioned (forgive me Christopher, I am not trying to be offensive. I say old-fashioned because I think of libraries such as MFC) deep-hierarchy OO point of view, I find myself thinking *way* into the future: what should I expect for this code to happen? What uses will it be put to? Hey, wouldn't it be clever if I made an abstraction X - then you could make plugins for module Y in some three or four years when I have the rest working?
The YAGNI principle has proven its value to me and I now find that very rarely, I need to make hierarchies - at least, I only make shallow ones, and more often, I can make functions. The power of a function (that manipulates NO GLOBAL VARIABLES, mind you) is that it doesn't contain any state which makes it easy to test - and it is easier for me to convince myself that it actually works. Combine that with immutable classes and you have very solid code.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Coupling is not neccessarily a bad thing!

Posted: May 3, 2005 8:13 AM

> Another point which I think is worth mentioning is that
> loosely coupled code is often more agile. Designing a
> class hierarchy seems very up-front to me.

Designing extremely loosely coupled code can be just as challenging. I think the issue is the fact that over-design is un-agile.

> If I consider
> some problem from an old-fashioned (forgive me
> Christopher, I am not trying to be offensive.

;-)

Consider the following example which represents the same algorithm moving towards decreased coupling:


int CountInstancesOf(const std::string& src, const std::string& pattern)
{ ... }


template<typename Sequence_T>
int CountInstancesOf(const Sequence_T& src, const Sequence_T& pattern)
{ ... }


template<typename Iter_T>
int CountInstancesOf(const Iter_T& src_begin, const Iter_T& src_end, const Iter_T& pattern_begin, const Iter_T& pattern_end)
{ ... }


template<typename SrcIter_T, typename PatternIter_T>
int CountInstancesOf(const SrcIter_T& src_begin, const SrcIter_T& src_end, const PatternIter_T& pattern_begin, const PatternIter_T& pattern_end)
{ ... }

Hopefully it is not contentious that indeed this represents a scale of decreasing coupling, but at the same time increasing complexity and decreased agility. The point I want to make here is that truly decreasing coupling can also have its disadavantages. Of course given all the time and the world and trying to write an industrial strength library (e.g. Boost, STL, STLSoft) the last choice is the way to go. When I am doing contractual work, and writing software the first choice is almost invariably the way to go.

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Coupling is not neccessarily a bad thing!

Posted: May 3, 2005 9:19 PM

> The problem (in this case) is exactly one caused by
> coupling. New requirements are not problems just a fact
> of life. The problem is the inability to meet the new
> requirement using the work that has been put into the
> existing solution.

The problem is that this article isn't even about coupling, as that term is commonly understood in the context of computer programming.

The example doesn't show any shared data (variables). Coupling is defined as logically separate pieces of code linked through shared data structures. The example doesn't have any shared data (class or instance variables), so we have to assume the presence of those variables to talk about coupling. Classes that inherit functions from a common base class do not create coupling between instances of those classes. Subclasses are certainly at risk when a common base class is modified, but that risk is not called coupling.

Derived classes are not coupled to their base class -- they are extensions of the base class. A derived class is logically equivalent to a single class that combines the functionality of the base and the derived class.

Multiple classes inheriting from the same base class inherit all of the same shortcomings of the model. But they are not necessarily coupled. In the example an object of type Cat and an object of type Bird are not coupled to each other unless one references a public variable of the other object, or a common class variable, or some global variable. Coupling is a property of objects, not of classes.

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Coupling is not neccessarily a bad thing!

Posted: May 3, 2005 9:37 PM

> Consider the following example which represents the same
> algorithm moving towards decreased coupling:

Your example shows increasing generality (and decreasing clarity). It doesn't demonstrate coupling.

I'm afraid that the original posting and most of the follow-ups are conflating coupling with other problems that have their own names: misuse of inheritance, the fragile base class problem, the difficulty of writing (and understanding) overly-generalized code, etc.

Here's an example of coupling:


class Pet {
    static int loudness = 10;

    void eat();
    ...
};

class Dog : Pet {
    void bark() { makebarkingsound(Pet::loudness); }
}

class Cat : Pet {
    void meow() { makemeowsound(Pet::loudness); }
}

Dog fido;
Cat fluffy;
...

The objects fido and fluffy are now coupled through the common class variable loudness. The objects are not coupled just because they derive from a common base class, nor are the subclasses coupled to their base class (unless objects of type Pet are instantiated, in which case those objects are coupled through the class variable).

Ged Byrne

Posts: 22
Nickname: gedb
Registered: Nov, 2003

Re: Coupling is not neccessarily a bad thing!

Posted: May 4, 2005 8:35 AM

The question is, what are you trading Coupling against?

It seems to me that Cohesion has been increased and Repetition has been reduced. These two benefits are worth the increase in coupling.

Cohesion is reduced because we now have a separate class, Pet, which is responsible for the common elements. In the first design the common elements occur in both Cat and Dog, so they are obviously not solely the responsibility of these classes.

This increase in cohesion has eliminated the need for repetition within the code.

It isn't about what is good and bad. It is about understanding the trade offs that we make.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Coupling is not neccessarily a bad thing!

Posted: May 4, 2005 8:41 AM

> The problem is that this article isn't even about
> coupling, as that term is commonly understood in the
> context of computer programming.
>
> The example doesn't show any shared data (variables).
> Coupling is defined as logically separate pieces of code
> linked through shared data structures.

That is an overly narrow defintion of coupling. Coupling occurs when modular sections of code are interconnected in such a way that changes to one section can potentially impact another. This can just as easily be an algorithmic or a type dependency. Coupling can as much occur in a functional programming language as an imperative one even though data structures can't be shared.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Coupling is not neccessarily a bad thing!

Posted: May 4, 2005 8:42 AM

> The question is, what are you trading Coupling against?
>
> It seems to me that Cohesion has been increased and
> Repetition has been reduced. These two benefits are worth
> the increase in coupling.
>
> Cohesion is reduced because we now have a separate class,
> Pet, which is responsible for the common elements. In the
> first design the common elements occur in both Cat and
> Dog, so they are obviously not solely the responsibility
> of these classes.
>
> This increase in cohesion has eliminated the need for
> repetition within the code.
>
> It isn't about what is good and bad. It is about
> understanding the trade offs that we make.

I am in agreement with Ged here. This was my intended point, though I think I did a poor job of demonstrating it.

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Coupling is not neccessarily a bad thing!

Posted: May 4, 2005 11:28 AM

> That is an overly narrow defintion of coupling. Coupling
> occurs when modular sections of code are interconnected in
> such a way that changes to one section can potentially
> impact another. This can just as easily be an algorithmic
> or a type dependency.

Dependency is not the same thing as coupling. If A and B don't share any global/class variables or data, but A calls B, A is dependent on B. Changes to B's behavior may affect A because A necessarily makes assumptions about B's behavior, not because they are coupled. The only way to eliminate all coupling is to not have A call B. If changes to B's internal implementation that don't affect it's external behavior or interface somehow affect A, then A and B are badly coupled.

If your program calls the library function strlen(), passing a single immutable parameter and receiving a single return value, that is called data coupling (from Myers' definition in Reliable Software Through Composite Design and Composite/Structured Design.). The only way to eliminate that coupling is to not make the function call. Because the only way to eliminate all coupling in non-trivial programs is to not use modules, it follows that some coupling is necessary, unless you are writing monolithic spaghettic code.

The question isn't, "Is coupling always bad?" The question is, "How can I reduce the amount of coupling, and how can I couple modules in the least fragile way?"

Following the same example, suppose the behavior of strlen() changes to return the length of the string including the terminator. Are the side-effects in your code properly blamed on coupling? No: your code is no more or less coupled to strlen() than it was before. The dependency on strlen()'s expected behavior causes the problem, not the necessary coupling through the function call.

I (perhaps wrongly) assumed we were talking about bad coupling, not the connections between modules required for them to work together. Your example doesn't demonstrate any of that kind of coupling. And I'm not convinced that inheritance in itself can be called coupling, because logically a subclass includes the base class -- they aren't coupled unless you do something with shared variables (class or global) or somehow make the base class aware of its subclasses.

indranil banerjee

Posts: 38
Nickname: indranil
Registered: Nov, 2004

Re: Coupling is not neccessarily a bad thing!

Posted: May 4, 2005 2:50 PM

> And I'm not
> convinced that inheritance in itself can be called
> coupling, because logically a subclass includes the base
> class -- they aren't coupled unless you do something with
> shared variables (class or global) or somehow make the
> base class aware of its subclasses.

I would say that there is very strong coupling between the Base and Derived types of a class hierarchy precisely because changes to Base's internal implementation that don't affect it's external behavior or interface can affect Derived.

Derived depends on Base's public and protected interface. So Derived is more exposed to changes in Base than other classes.

If Base's non virtual methods call virtual methods (like in the Template Method design pattern), Then subclasses can definitely change the behaviour of Base class methods.

Dont get me started on C++'s Curiously Recurring Template Pattern where the Derived type is a template parameter of the Base type.

Every time we introduce a relation between types we have the option of expressing that relationship through inheritance.

Even simple HAS-A relationships can be implemented as private inheritance. The reason that this is not recommended is because of the needlessly strong coupling that it would introduce.

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Coupling is not neccessarily a bad thing!

Posted: May 4, 2005 4:31 PM

> I would say that there is very strong coupling between the
> Base and Derived types of a class hierarchy precisely
> because changes to Base's internal implementation that
> don't affect it's external behavior or interface can
> affect Derived.

If you define coupling to mean the same thing as dependent, you are right. Coupling is a specific type of dependency in the context of programming. Inheritance is another type of dependency. The fragile base class problem you describe is a consequence of inheritance dependency. I wouldn't call it coupling -- it's a different kind of problem.

> Derived depends on Base's public and protected interface.
> So Derived is more exposed to changes in Base than other
> classes.

No, Derived either shares or replaces Base's public and protected interface. Logically Derived is sensitive to changes in Base because Base's internals are also Derived internals.

indranil banerjee

Posts: 38
Nickname: indranil
Registered: Nov, 2004

Re: Coupling is not neccessarily a bad thing!

Posted: May 4, 2005 6:07 PM

> If you define coupling to mean the same thing as
> dependent, you are right. Coupling is a specific type of
> dependency in the context of programming. Inheritance is
> another type of dependency.

Hmmm, I dont want to quibble over definitions. But I'd like to ask you one question.

Say you have 3 types A, B and C. Where B is derived from A. And C has a member variable of type A.

Do you consider there to be greater coupling between B and A or between C and A?

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Coupling is not neccessarily a bad thing!

Posted: May 4, 2005 11:40 PM

> Hmmm, I dont want to quibble over definitions. But I'd
> like to ask you one question.

I don't want to quibble either. But if we're going to talk about coupling we should agree on what it means. Perhaps my definition is outdated, but it is how I've understood the term since 1975. Obviously the books I learned about coupling from did not contemplate the additional risks of object-oriented programming languages.

> Say you have 3 types A, B and C. Where B is derived from
> A. And C has a member variable of type A.
>
> Do you consider there to be greater coupling between B and
> A or between C and A?

Inheritance creates a greater dependency between B and A, but as I've said I don't believe that dependency is the same as coupling. Coupling is a particular kind of dependency caused by modules sharing data or data structures, or by parameters that encode behavior rather than data (control coupling).

B has access to A's public and protected methods and variables. C only has access to A's public methods and variables. If A's public interface is changed both B and C may be affected. If A's protected interface is changed only B is at risk. Inheritance exposes more of the base class internals to the derived class than composition does. However if C has to republish A's public interface with forwarding functions C becomes dependent on A in much the same way that B is.

Whether we call that coupling or not, it isn't necessarily bad for B and C to be dependent on A -- every connection between modules is a dependency, and dependency means that changes to one may affect the other. When the dependency is through a global variable the modules are dependent in a hard-to-see and dangerous way.

Flat View: This topic has 35 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic