Take the 2-minute tour ×

I have a software patterns exam this week and one of the topics we are to study is Efferent and Afferent coupling.

I understand a package has a high Ce (efferent coupling) if it depends on a number of other types.

For example:

class Car{
    Engine engine;
    Wheel wheel;
    Body body;

This class would have a high efferent coupling because it depends on the Engine, Wheel and Body types.

Whereas the type "Wheel" would have a high Ca (afferent coupling) if several other packages depended on it (Car, Plane, Bicycle).

One of the possible questions on our exam is, when is Efferent / Afferent coupling good or bad? This seems odd to me because logically a program would need packages / classes with both high Efferent / Afferent coupling.

Does anybody have an example of when / where high efferent or afferent coupling is good / bad??

Thanks !

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

Afferent coupling can most easily be assessed in terms of how much pain it causes/saves because of change necessity or likelihood. For instance, take your wheel class and let's say that a lot of other modules use it to build various kinds of vehicles. If the wheel class is extremely stable, then this afferent coupling is beneficial since vehicles need wheels and they're using a reliable one. If, on the other hand, the wheel class is volatile in terms of maintenance, this afferent coupling is going to be a pain point as you introduce breaking changes repeatedly to lots of code.

Efferent coupling is similar in concept, but you're going to be looking at a slightly different value proposition. If you have a car class that depends directly upon a lot of individual parts (as opposed to say "Engine" and "Chassis" only, and they consist of other sub-parts), the class probably does a lot and may thus be a maintenance bottleneck. Changes to that class are likely to be difficult and risky because of its complexity. On the other hand, if the efferent coupling is high, but it's actually pretty cohesive and clear, then you don't have a hierarchy of objects and relationships to worry about.

When it comes to architecture/design, what you really have to consider are pretty much endless tradeoffs and these metrics are no different. If you want to figure out an example of something being good or bad, play the "what if" game. Imagine an example and say "what if I wanted to do X -- how much would that suck?" For X where the answer is "a lot," you have a disadvantage and for X where the answer is "that'd actually be really easy" you have an advantage.

share|improve this answer
add comment

Speaking in generalities, loose coupling:

positive: protects a portion of the system from changes in something that it depends on (afferent coupling)

negative: the relationship may be more difficult to understand

For example, if I were developing a system that relied on HTTTP, I would decide if I need to tightly or loosely couple to HTTP. If I thought that the system were likely to switch to a different protocol, I may choose to loosely couple to it, while if I accepted that HTTP were my protocol, I could tightly couple to that protocol for simplicity in understanding.

Consider that some of the complexities in WS* are in its decoupling from HTTP as a protocol.

share|improve this answer
add comment

Your Answer


