Coupling

[Farouk Mohamed1]

What is brittle coupling, can anyone please explain.
Does it mean coupling is stronger or does it mean it is weaker as it can be easily broken
Farouk

[Desai Sandeep]

Hi Farouq,
Brittle coupling means high coupling.I have answered to a similar question you posted on Product and Catalog.
Hope this helps,
Sandeep

[Paul Newton]

Further to Sandeep's post (apologies if I have the name wrong):
Highly coupled systems contain subsytems/classes that are highly dependent on each other. Small changes to one part of the system, have far reaching effects throughout the rest of the system. Hence, the system easily breaks (brittle).
regards,
paul.

[Desai Sandeep]

Hi Paul,
You have got my name exactly right!
What you have mentioned about brittle systems is in place.This is the reason why Martin Fowler mentions in his book somewhere that by dividing the classes into packages the transitive effect of the changes made at the package level can be minimized.
Regards,
Sandeep
SCJP2, OCSD(Oracle JDeveloper), OCED(Oracle Internet Platform)
[This message has been edited by Desai Sandeep (edited August 31, 2001).]

[Adrian Ferreira]

Originally posted by Desai Sandeep:
This is the reason why Martin Fowler mentions in his book somewhere that by dividing the classes into packages the transitive effect of the changes made at the package level can be minimized.

Sandeep,
Even though I understood what you mean, I think it would be better to say a little different and do not use the word transitive since the dependency between packages are not transitive. See Fowler, second edition pg 109.
If you create package, export only a subset of operations as public and keep the rest of operations as private, you can reduce class dependency.
Cheers,
Adrian

[Desai Sandeep]

Hi Adrian,
I've read Martin Fowler chapter, where he mentions that dependencies between packages should not be transitive.Martin puts the definition of transitive effect as having to make a change in Package B and Package C, as a result of change in Package A.
However, as it usually happens, if you make a small change in Package A, you almost certainly have to makes changes to a dependent Package B.This will have an effect on Package C which is dependent on Package B.
In our case, Package B is shielding changes in Package C due to changes in Package A.However, as I mentioned before, you will still need to make changes in Package B due to its dependency with Package A, which will eventually affect Package C due to its dependency with Package B.
In a way, this is very similar to the definition of transitivity which Martin has mentioned in his book; the difference however being the additional shielding that takes place, which again is only as strong as the dependency between packages.
Ideally, we wouldn't have wanted this "roll-over" or transitive effect to happen!However,looking at the above situation, we can infer that it is impossible to remove the transitive effect completely - we can however take steps to reduce it, by dividing the classes in proper packages and minimizing the dependencies as much as possible.
This is my view on Martin's discussion on on transitive effect and packages.
Comments, please!
Thanks,
Sandeep
SCJP2, OCSD(Oracle JDeveloper), OCED(Oracle Internet Platform)
[This message has been edited by Desai Sandeep (edited September 01, 2001).]

[Adrian Ferreira]

Sandeep,
I see we both understood that chapter in Fowler book. Also, I appreciate a lot your comments. I have only one more point.

However, as it usually happens, if you make a small change in Package A, you almost certainly have to makes changes to a dependent Package B.

... almost certainly is difficult to say. It depends which methods you export in your public interface. It is possible to keep public interface in package C even with changes in package B. So, package dependency does not imply transitive dependency. Now, other different question: can package dependency be transitive? As you explained very well in your last post, there is no doubt it can.
That is the point I would like to clear.
Cheers,
Adrian

[Desai Sandeep]

Adrain,

Originally posted by Adrian Ferreira:
[..]It depends which methods you export in your public interface. It is possible to keep public interface in package C even with changes in package B.[..]

I get what you say.But again, exporting methods to a public interface is applying a design pattern, in this case a Facade Pattern, which can be used to reduce transitivity.Martin has actually clubbed this together in his book with package dependencies.But if we look at package dependencies in isolation (without applying this pattern), we would realise that package dependencies do tend to be transitive in nature.
Does this make sense?
Regards,
Sandeep
SCJP2, OCSD(Oracle JDeveloper), OCED(Oracle Internet Platform)

[Adrian Ferreira]

Sandeep,

Originally posted by Desai Sandeep:
But if we look at package dependencies in isolation (without applying this pattern), we would realise that package dependencies do tend to be transitive in nature.
Does this make sense?

Yes, I think it makes sense.
Thanks for your good comments,
Adrian

[zaeem masood ashar]

Originally posted by Desai Sandeep:
I've read Martin Fowler chapter, where he mentions that dependencies between packages should not be transitive.

Hi,
Fowler categorically says that with packages, the dependencies are not transitive. So if A is dependent on B and B is dependent on C, a change in A should not warrant a change in C. However, B has to be explored and changes if any are to be remedied
------------------
SCJP2
[This message has been edited by zaeem masood ashar (edited September 03, 2001).]

[Desai Sandeep]

Hi Zaeem,
Please read my views posted earlier, on this.Ideally we would have liked it the way Martin puts it, but the question is can you really stop transitivity just using packages?
-- Sandeep
[This message has been edited by Desai Sandeep (edited September 04, 2001).]