Difference between Loose Coupling and Tight Coupling in Java With Examples

First to understand what is Loose coupling and Tight coupling and also to know the  advantage of loose coupling.

Loose coupling means reducing the dependencies of a class that uses the different classes directly. 
Tight coupling means classes and objects are dependent on one another.

In general tight coupling is usually not good because it reduces flexibility and re-usability of code and it makes changes much more difficult and not easy to test.

Tight Coupling:-

      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 and there is chance of overlooking changes.(Source- from StackOverflow).
         See below code is for tight coupling.

   public class Journey {
         Car car = new Car();
         public void startJourney() {
               car.travel();
         }
   }

   public class Car {
         public void travel () {
              System.out.println("Travel by Car");
         }
   }

         In the above code the Journey class is dependents on Car class to provide service to the end user(main class to call this Journey class).
         In the above case Journey class is tightly coupled with Car class it means if any change in the Car class requires Journey class to change. For example if Car class travel() method change to journey() method then you have to change the startJourney() method will call journey() method instead of calling travel() method.
       
      See below code,


  public class Journey {
        Car car = new Car();
        public void startJourney() {
               car.journey();
        }
  }

  public class Car {
        public void journey () {
              System.out.println("Travel by Car");
        }
  }

         The best example of tight coupling is RMI(Remote Method Invocation)(Now a days  every where using web services and SOAP instead of using RMI, it has some disadvantages).

 Loose Coupling:-

        Loose coupling is a design goal that seeks to reduce the inter-dependencies between components of a system with the goal of reducing the risk that changes in one component will require changes in any other component. Loose coupling is much more generic concept intended to increase the flexibility of system, make it more maintainable and makes the entire framework more stable.
   
Below code is an example of loose coupling,


   public interface Vehicle {
        void start();
   }
       
   public class Car implements Vehicle {
        @Override
        public void start() {
              System.out.println("Travel by Car");
        }
   }

   public class Bike implements Vehicle {
         @Override
         public void start() {
               System.out.println("Travel by Bike");
         }
   }
           
    // create main class Journey
   public class Journey {
         public static void main(String[] args) {
               Vehicle v = new Car();
               v.start();
         }
   }

        In the above example, Journey and Car objects are loosely coupled. It means Vehicle is an interface and we can inject any of the implemented classes at run time and we can provide service to the end user.

        The examples of Loose coupling are Interface, JMS, Spring IOC(Dependency Injection, it can reduce the tight coupling).

Advantages Of Loose coupling:-

         A loosely coupled will help you when your application need to change or grow. If you design with loosely coupled architecture, only a few parts of the application should be affected when requirements change. With too a tight coupled architecture, many parts will need to change and it will be difficult to identify exactly which parts will be affected. In short,

 1) It improves the testability.                                                     
 2) It helps you follow the GOF principle of program to interfaces, not implementations.
 3) The benefit is that it's much easier to swap other pieces of code/modules/objects/components when the pieces are not dependent on one another.
 4) It's highly changeable. One module doesn't break other modules in unpredictable ways.