Dependency Injection Principle

Suppose there are two classes - A.java and B.java where A.java consumes B.java as below-
class A{
   B b = new B();
} 

The above code shows that the two classes are tightly coupled and hence have following drawback-

  • In case class A wishes to switch to another class instead of B, say class C then we need to make changes in class A which is not desireable.
  • If A is further inherited by other classes, then change mentioned in point 1 will affect ALL the child classes. 
  • Testing of class A will be difficult because its directly using B hence, mocking of class B is not possible. 
One solution to above problem is -
   class A{
      B b;
   }

But here, we are asking the calling class to initialize class B for A, which is not a good practise. Also, it still holds above concerns.

The above issue is resolved by 'Dependency Injection Princple' which states that - Two classes should be loosely coupled. This can be achieved by an interface or abstract class defining contract between the two.

That means,

interface Binterface {
}

class B implements Binterface {
}

class A {
   Binterface binterface;
}

Because of the above principle,
  1. Interface defines contract between consumer class and its child.
  2. Consumer class A relies on interface/adapter class to consume concrete class.
  3. This allows consumer class A to consume any class of type Binterface
  4. The consumer class A do not initialise the consumed class B, this leads to 'separation of concern'
  5. Also, we can easily mock the consumed class B and test the Consumer class A.
  6. And Class A can consume any class of type Binterface.
The only disadvantage of this principle is -
      As the class to be injected in consumer class happens in runtime, it wont give any compile time error.



Comments

Post a Comment

Popular posts from this blog

S.O.L.I.D. Class Design Principles

Abbreviation Full Form Definition Reason S Single Responsibility Principle A class should have only one reason to change i.e. should have only one purpose to serve.  - loosely coupled - less change lead to less break down of application - helps to change identity of object without affecting other modules O Open-Closed Principle A class should be open for extension closed for modification. - Anyone need to make change in your class has to inherit the class and change. This allows the existing functionality to stay intact. L Liskov Substitution Principle Derived types should always be substitutable by its parent class (base type). Derived types should be compatible with its base type. For e.g.: Square is a Rectangle i.e. Square represents a Rectangle. In case, if we try to set dimension of a Rectangle reference pointing to Square instance, the flow will be weird as it will always override the dimension of rectangle. I Interface Seg...
Read more

Spinner for Dropdown

Image
Spinner helps you to display the set of data (collection). It allows teh data to be displayed in drop down fashion. Example: 1. Lets define a static String array in Android XML file. <? xml version= "1.0" encoding= "utf-8" ?> < resources > < string-array name= "countries" > < item >India</ item > < item >U.A.E.</ item > < item >Nepal</ item > < item >China</ item > < item >Australia</ item > < item >United States</ item > < item >Europe</ item > < item >United Kingdom</ item > < item >Australia</ item > < item >Canada</ item > < item >Japan</ item > < item >Singapore</ item > </ string-array > </ resources > 2. Configure Spinner in your activity...
Read more

@Overrride annotation introduced in Java1.5

Whenever we have a subclass that implements parent method it is marked with annotation as @Override. This is to make compiler know that the child overrides the method defined or declared in parent. If @Overrride annotation is commented, the subclass will work as it was. But if in future, the signature of parent class changes, the compiler wont ask to implement the method instead it will think subclass has overloaded the method present in base class. If you uncomment @Override annotation, the compiler will throw compile time error as method signature in parent class has changed. Annotation should be used as standard as- It ensures that for any change in method signature of parent class, compiler will ask to change it for the subclasses.    Also it is better to resolve issue in compile time rather than runtime
Read more