what is loose coupling and tight coupling in oop ( java )

Question

i have some confusion regarding loose coupling and tight coupling in java.as i know loose coupled means least information about each other and tight coupled means dependency.as we know loose coupling can achieve through interface implementation and inheritance make tight couple.

for example:

1) A (interface)<--------------------- B (class)

2) C ( class ) <--------------------- D (class)

suppose these four classes is part of my entire application, making change in B or D do not make any impact on application(for running point of view). removing any method or variables from A or C required so many change in application. all right score is 2-2, but adding new method in C or A is different. if i added new method in C do not impact on application but in adding in A , at least i have to override this method in B and all the classes that implement interface A. so how it's loose coupling at least in this scenario. my doubt is, is inheritance give always tight coupling.i learned Inheritance is one of powerful tool of OOP.for designing if a class follow the "is a relationship" then use inheritance. loose coupling means less information about each other. A and C both don't know in future which class is going to implements or extends,but after adding B and D now B is not dependent on A because it's all method's are abstract, but D can also override the inheriting feature.

Answer 1

as we know loose coupling can achieve through interface implementation and inheritance make tight couple.

I think you got that wrong. "coupling" is usually about 2 different classes that know each other either by their concrete class or just by some interface.

Let's say 2 classes A and B need to comunicate with each other.

 A <--knows--> B

Methods in A would have some parameter B and methods in B have a parameter of type A. E.g. like

 class A {
     public void talkTo(B b) {}
 }    

Now that's a tight coupling between A and B because every change you do to these classes can make changes in the other class necessary.

If you do it loosely coupled they both expose themselves through some interface. ("interface" can mean abstract class too - that's a choice the respecive side.)

   IA  <-- A
     ^     |
      \   /
        X           < loose coupling between the A side and the B side
      /   \
     v     |
   IB  <-- B     < pretty tight coupling betwen IB and B

and communication between them goes via those interfaces

   class A implements IA {
        public void talkTo(IB b);
   }
   class B implements IB {
        public void talkTo(IA a);
   }

The dependency between A and IA (that's what you seem to look at) is not what tight vs loose coupling is primarily about. There is some similarity but loose coupling doesn't mean that you should implement an interface vs. extend an abstract class. It's usually better to implement just an interface though.

If you can replace an "IS A" relation with a "HAS A" relation you do essentially the same. You decouple yourself (e.g. you are A) from a concrete implementation and only need to depend on the encapsulated other side (e.g. from the B side). Inheritance is indeed a very powerful feature but it is often misused.

Answer 2

Short Introduction Loose and Tight Coupling

Loose Coupling means reducing dependencies of a class that use a different class directly. In tight coupling, classes and objects are dependent on one another. In general, tight coupling is usually bad because it reduces flexibility and re-usability of code and it makes changes much more difficult and impedes testability etc.

Tight Coupling

A Tightly Coupled Object is an object that needs to know quite a bit about other objects and are usually highly dependent on each other's interfaces. Changing one object in a tightly coupled application often requires changes to a number of other objects. In a small application we can easily identify the changes and there is less chance to miss anything. But in large applications these inter-dependencies are not always known by every programmer or there is a chance of overlooking changes. But each set of loosely coupled objects are not dependent on each other.