how can be achieve loose coupling.

[sarojni agrwal]

Hi all, I am confused in loose coupling in java, as I know and read, I got to know that loose coupling can be achieve in two ways:
1)by encapsulation 2) by Interface ...am I right?


This is by encapsulation:1part

package inhertnce;

public class loose {

	
	private String car;
	private String bike;
	
	public void Setcar(String value)
	{
		car = value;
	}
	
	
	
	
	
	public String getcar()
	{
		return car;
	}
	
	
	public static void main(String[] args) {
		
		
		loose lp = new loose();
		lp.Setcar("car");
		
		System.out.println("car value " + lp.getcar());
		
		
		
		
		
	}

}

output is car....


2part if give value is bike then output is bike no need to change code; only value change lp.Setcar("bike");
whole code as it is...

package inhertnce;

public class loose {

	
	private String car;
	private String bike;
	
	public void Setcar(String value)
	{
		car = value;
	}
	
	
	
	
	
	public String getcar()
	{
		return car;
	}
	
	
	public static void main(String[] args) {
		
		
		loose lp = new loose();
		lp.Setcar("bike");
		
		System.out.println("car value " + lp.getcar());
		
		
		
		
		
	}

}

output is bike..


but by interface , I can not understand, how can I achieve loose coupling by interface, can anyone tell and explain me with programming example?

[Tushar Goel]

Both the example is same. There is no difference. And also neither of them showing loose coupling..

Also there are several issues in this.. ex: Class name always start from capital, Setcar should be setCar..

Here is an example below you can see vehicle class is an interface and drive is a method which can be used with any instance
of the class which implements Vehicle..

public interface Vehicle {
  void drive() ;
}

public class Car implements Vehicle {

	@Override
	public void drive() {
		System.out.println("Car is running..");
	}
	
}

public class Bus implements Vehicle {
	@Override
	public void drive() {
		System.out.println("Bus is running..");
	}
}

public class Test {
	public static void main(String[] args) {
		Vehicle car = new Car();
		car.drive();
		
		Vehicle bus = new Bus();
		bus.drive();
	}
}

[Ganish Patil]

Please refer this Java Programming Style Guide http://www.javaranch.com/style.jsp for naming convention.

[Jason Bullers]

I think the code example needs to be a little larger than what you showed in your "Loose" class in order for you to start to see and understand how to minimize coupling. Others might have better examples, but this was the first (simplest) example that popped in to my head. I'll start with an implementation that has high coupling and then refactor it to encapsulate information and use dependency injection.

Imagine you have a mechanic. One of the things this mechanic does is checks tire pressure on car tires. We could try modeling that like this:

class Mechanic {

  boolean checkTirePressure(Car car) {
    for (Tire t : car.getTires()) {
      if (t.getPressure() < 32) return false;
    }

    return true;
  }

  public static void main(String[] args) {
    Car car = new Car();
    Mechanic mechanic = new Mechanic();

    System.out.println("Tires okay? " + mechanic.checkTirePressure(car));
    car.drive(40);
    System.out.println("Tires okay? " + mechanic.checkTirePressure(car));
  }
}

class Car {

  private Collection<Tire> tires;

  Car() {
    tires = asList(
                new Tire(34),
                new Tire(34),
                new Tire(34),
                new Tire(34)
            );
  }

  void drive(int distance) {
    for (Tire t : tires) {
      t.deflateBy(distance / 10);
    }
  }

  Collection<Tire> getTires() {
    return unmodifiableCollection(tires);
  }
}

class Tire {

  private int pressure;

  Tire(int pressure) {
    this.pressure = pressure;
  }

  void deflateBy(int pressure) {
    this.pressure -= pressure;
  }

  int getPressure() { return pressure; }
}

The above example is not loosely coupled: the Mechanic knows about Tire pressure, even though that's an attribute of Tire, which in turn belongs to Car; and there is no way that we could build a Car with different tires (e.g. with a different initial pressure or different low pressure threshold). This is bad primarily because if anything about the Tires changes, the Mechanic class (two levels removed from Tire!) may be impacted. However, if we did something like this, we could reduce the coupling:

class Mechanic {

  boolean checkCarIsInWorkingOrder(Car car) {
    return car.performDiagnostics();
  }

  public static void main(String[] args) {
    Car car = new Car(asList(
                  new Tire(32, 34),
                  new Tire(32, 34),
                  new Tire(32, 34),
                  new Tire(32, 34)
                ));
    Mechanic mechanic = new Mechanic();

    System.out.println("Tires okay? " + mechanic.checkCarIsInWorkingOrder(car));
    car.drive(40);
    System.out.println("Tires okay? " + mechanic.checkCarIsInWorkingOrder(car));
  }
}

class Car {

  private Collection<Tire> tires;

  Car(Collection<Tire> tires) {
    tires = new ArrayList<>(tires);
  }

  void drive(int distance) {
    for (Tire t : tires) {
      t.deflateBy(distance / 10);
    }
  }

  boolean performDiagnostics() {
    for (Tire t : tires) {
      if (t.isPressureLow) return false;
    }

    return true;
  }
}

class Tire {

  private final int minimumPressure;
  private int pressure;

  Tire(int minimumPressure, int initialPressure) {
    this.minimumPressure = minimumPressure;
    this.pressure = initialPressure;
  }

  void deflateBy(int pressure) {
    this.pressure -= pressure;
  }

  boolean isPressureLow() {
    return pressure < minimumPressure;
  }
}

In this example, you can see that the dependency that Car has on Tires has been injected; instead of creating its dependencies itself, Car is given its dependencies at construction time. This makes it very easy to create Cars with different types of Tires. It is an especially useful concept for writing testable software, but I won't go into that right now. It works extremely well with interfaces: you expect an interface at construction time and let the context determine what concrete type it should be. For example, say Tire was an interface and we had AllSeasonTire and WinterTire as concrete implementations. When the Car was assembled, perhaps we find that it is late Fall. We could then decide to build the Car with four WinterTires (if the customer paid for them) instead of AllSeasonTires.

Similarly, the coupling between the Mechanic and the Tires is gone. Now, the Mechanic only talks to the Car. If we change the Car and add additional components to it that need to be checked to ensure the Car is in working order, the Mechanic doesn't need to care (the class doesn't need to change). If we change the type of Tires we used to assemble the Car to have different minimum pressures, the Mechanic isn't affected.

Hope that helps.