Doubt about Inheritance and Coupling

[Carlos Ortega]

Hi there, here is a question that I have not able to answer correctly, so I would appreciate any help:

Assuming that this definition of coupling (or dependency ) is correct ( => "the degree to which each program module/class relies on each one of the other modules/classes")

Can we say that if we define a inheritance relationships between 2 classes we are really incrementing the "degree" of coupling between them?

....in other words... does inheritance relationship defines a dependency relationship between the classes?

[Ernest Friedman-Hill]

Hi,

Welcome to JavaRanch!

First, a bit of business: you may not have read our naming policy on the way in. It requires that you use a full, real (sounding) first and last name for your display name. Nicknames or "handles" aren't acceptable here. You can change your display name here. Thanks!

To answer your question: absolutely, yes -- but it's a one-way relationship. The child depends on the parent, but not the other way around.

[Jaime M. Tovar]

Using my own logic and the emphasis in the class concept in your definition, I can tell yes, because a child class depends on the parent class to do its work�

But by definition usually dependency is used in a context of modules, not just a single class. You usually don�t need to care too much about how much a class depends on other classes as long as it is clear the responsibility of each class.

And in fact there are many gray areas. For example an abstract class depends on a child class, if there is no child class there is no one to do the work.

[Stan James]

Well, let's define dependency (for the moment) as

A depends on B when:
* B must be present for A to compile
* if B changes, A might break

So any kind of inheritance or direct reference to another type is a dependency and a form of coupling.

We can break this chain of coupling pretty easily. Let's say A has a variable of type X where X is an interface. B implements X. Now can compile and "jar up" A without B. Changing B doesn't break A. We can say we've decoupled A and B. But we've made A and B both depend on X which is something we want to watch closely.

By this definition I would disagree with "an abstract class depends on its child" because we can compile and distribute the abstract class without any children. Consider all the interfaces in JDBC ... there's no dependency or coupling with MySQL in there.

There was mention of "modules" above, which are not clearly defined in Java (yet). For now, jars are common units of deployment. My team recently ran into trouble with circular dependencies between two jars. Our automated build script starts from scratch, checks out the source code for one jar at a time and builds it. It's not possible to compile and build either jar without the other. Oops.

Wikipedia has a list of types of coupling. All this is pretty much just one on the list. See what you think of the others.

[Jaime M. Tovar]

In your concept of decoupling you are decoupling the implementation, but you depend on the definition (the interface) to even compile. So you can compile A but it still depends on X (or its implementation).

I wrote about the example of the abstract class because I focused in the working part. You can define the abstract class without depending in the child. Without the child, there is no-one to do the work at run time so you still depend on the implementation execute. But it is just my opinion.

A jar is not a good translation of a module in java world. A jar is a way of packaging as you have said. But you still can have a complete module without even a jar.

There are times you can compile a jar without one or more specific implementations. For example you can work with a Connection interface without knowing which JDBC specific implementation you will be using at run time. You still depend on the JDBC definition.

I think all the coupling examples in the wikipedia reference, use the module concept to explain the characteristics of each specific example. I think that�s because dependencies are used usually al module level of abstraction.