What is coupling and how/why should it be avoided?
I always hear that good software design avoids coupling but I don't know what that means exactly.
Here's an example: I wrote a set of class wrappers for rendering 2D shapes. Later on I wrote another set of classes for implementing custom GUI controls. Obviously GUI's are graphical but other than that these classes aren't related to the graphical classes.
I'm doubting whether the GUI classes should be aware of the graphics classes. Is this a problem of coupling? What would you do in this instance to have the GUI controls eventually rendered by the graphics objects?
This might seem like a dumb question but my instinct is to include "graphics.h" inside "gui.h" and not worry about it but, I have a feeling this is the wrong thing to do.
Here's an example: I wrote a set of class wrappers for rendering 2D shapes. Later on I wrote another set of classes for implementing custom GUI controls. Obviously GUI's are graphical but other than that these classes aren't related to the graphical classes.
I'm doubting whether the GUI classes should be aware of the graphics classes. Is this a problem of coupling? What would you do in this instance to have the GUI controls eventually rendered by the graphics objects?
This might seem like a dumb question but my instinct is to include "graphics.h" inside "gui.h" and not worry about it but, I have a feeling this is the wrong thing to do.
Wow, no one has answered this yet...
http://en.wikipedia.org/wiki/Coupling_(computer_programming)
If "gui.h" uses the stuff in "graphics.h", then it is appropriate to include it -- even if your system is designed to allow the user to change out the graphics primitives.
Only if your GUI requires the user to explicitly provide a graphics base to instantiate it should you not include a default header. Some would say this is the superior design, because your system is very lightly coupled -- the only requirement is that the primitives exist with the required interfaces.
That said, there's very good and there's perfection. Very good is often good enough. Go ahead and follow your instinct. It isn't wrong.
Hope this helps.
http://en.wikipedia.org/wiki/Coupling_(computer_programming)
If "gui.h" uses the stuff in "graphics.h", then it is appropriate to include it -- even if your system is designed to allow the user to change out the graphics primitives.
Only if your GUI requires the user to explicitly provide a graphics base to instantiate it should you not include a default header. Some would say this is the superior design, because your system is very lightly coupled -- the only requirement is that the primitives exist with the required interfaces.
That said, there's very good and there's perfection. Very good is often good enough. Go ahead and follow your instinct. It isn't wrong.
Hope this helps.
Duoas said:
Can you honestly tell me that you don't think this is one of those topics that could potentially devolve into a flame war? I saw this post yesterday and had half a response typed out but then just cancelled it, mainly due to the bias of that very Wiki article that you posted. Here is more or less how I saw the conversation going:
Me:
"The whole 'Coupling is evil' mindset is a Strawman argument made by people who nit pick over non-existent problems. This is a non-issue for properly encapsulated objects since any changes to objects that are higher up on the tree so to speak would not effect the operation of the children of those objects since the later would only be using the parent classes data members through virtual functions."
Someone Else:
"Coupling is the result of an inherent design flaw! It increases the complexity and\or difficulty of the maintaining the code and needlessly ties children to specific instances of parent classes. Custom objects should be made to be flexible and modular, by using a template design for example, so that they may be reused again on other projects instead of being one off solutions that only address the current problem at hand." Also, depending on the person responding I was expecting something along the lines of "@Computergeek: Coupling is the result of improperly encapsulated objects or encapsulation not being applied at all" or "Coupling is the antithesis of encapsulation."
Would you like to add anything? Should we pick up from here? My conclusion by the way was that this is one of those philosophies of programming and as with any philosophy it will have varying schools of thought.
| Wow, no one has answered this yet... |
Can you honestly tell me that you don't think this is one of those topics that could potentially devolve into a flame war? I saw this post yesterday and had half a response typed out but then just cancelled it, mainly due to the bias of that very Wiki article that you posted. Here is more or less how I saw the conversation going:
Me:
"The whole 'Coupling is evil' mindset is a Strawman argument made by people who nit pick over non-existent problems. This is a non-issue for properly encapsulated objects since any changes to objects that are higher up on the tree so to speak would not effect the operation of the children of those objects since the later would only be using the parent classes data members through virtual functions."
Someone Else:
"Coupling is the result of an inherent design flaw! It increases the complexity and\or difficulty of the maintaining the code and needlessly ties children to specific instances of parent classes. Custom objects should be made to be flexible and modular, by using a template design for example, so that they may be reused again on other projects instead of being one off solutions that only address the current problem at hand." Also, depending on the person responding I was expecting something along the lines of "@Computergeek: Coupling is the result of improperly encapsulated objects or encapsulation not being applied at all" or "Coupling is the antithesis of encapsulation."
Would you like to add anything? Should we pick up from here? My conclusion by the way was that this is one of those philosophies of programming and as with any philosophy it will have varying schools of thought.
I see no reason why this should get any flames. Further, the OP is asking a reasonable question: "What the heck is this coupling thing I'm supposed to be avoiding (supposedly)? Is <my example> relevant? What should I do (and/or believe)?"
The Wiki article is not particularly biased; the claims it makes against improperly coupled objects are regularly seen in actual systems maintenance nightmares.
Further, what about my response invited any of this? Was it not reasonable? Or was it incorrect?
Strong coupling must occur at some level; what level that is is set right at the beginning of a project with the requirements specification and validated with design prototypes and testing. All this, of course, is probably over OP's head.
But a specific response about a specific problem isn't. And it (hopefully) sheds light on the bigger issue when he, someday future, revisits it. Dealing with coupling is one of the basic issues in programming; everyone must learn to handle it. It doesn't mean they need to be on the cutting-edge holy language/program design wars.
The Wiki article is not particularly biased; the claims it makes against improperly coupled objects are regularly seen in actual systems maintenance nightmares.
Further, what about my response invited any of this? Was it not reasonable? Or was it incorrect?
Strong coupling must occur at some level; what level that is is set right at the beginning of a project with the requirements specification and validated with design prototypes and testing. All this, of course, is probably over OP's head.
But a specific response about a specific problem isn't. And it (hopefully) sheds light on the bigger issue when he, someday future, revisits it. Dealing with coupling is one of the basic issues in programming; everyone must learn to handle it. It doesn't mean they need to be on the cutting-edge holy language/program design wars.
I'm not attacking you Duoas, I'm just stating one possibility for why the question in the title was not answered yet. I avoided this topic at first because, to me, it was a question about why one design philosophy is the best.
Topic archived. No new replies allowed.