Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Doubt about Inheritance and Coupling

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
author and iconoclast
Posts: 24203
43
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ruth Stout was famous for gardening naked. Just like this tiny ad:
the value of filler advertising in 2020
https://coderanch.com/t/730886/filler-advertising
    Bookmark Topic Watch Topic
  • New Topic