CODEWITHSUNDEEP
javadependency-injection
user544079
user544079

Reputation: 16639

Dependency injection java

Is the following a valid example of Dependency injection. 

public class Employee {
    private String name;
    private String company;

    public Employee(String name, String company){
        this.name = name;
        this.company = company;
    }

    public String getName(){
        return name;
    }
    public void setName(String name){
        this.name = name;
    }
    public String getCompany(){
        return company;
    }
    public void setCompany(String company){
        this.company = company;
    }
}

Application class has dependency on Employee

public class Application {

    private static Employee emp;
    private static String name;
    private static String company;

    public Application(Employee emp){
        this.emp = emp;
    }

    public static String getApplication(){
        name = emp.getName();
        company = emp.getCompany();
        return "Name: " + name + "\nCompany: " + company;
    }
    public static void main(String[] args) {
        // TODO Auto-generated method stub
        Employee emp1 = new Employee("John", "ABC");
        Application app1 = new Application(emp1);
        System.out.println(app1.getApplication());
    }

}

Upvotes: 1

Views: 214

Answers (3)

mkbrv
mkbrv

Reputation: 407

First of all you might want to read about when to use dependency injection. Injecting an instance of a simple class with no functionality makes no sense to me.

You usually use an interface for a class that has also behaviour and it is more than a wrapper of data. Remove the static and maybe add a final and in your injection send an instance of an implementation for that interface.

Like this:

public class TextEditor {
   /*Interface SpellChecker**/
   private final SpellChecker spellChecker;
   private String text; 

   /**An implementation for the SpellChecker is provided*/
   public TextEditor(final SpellChecker spellChecker) {
      this.spellChecker = spellChecker;
   }

   public Boolean spellCheck(){
      return this.spellChecker.isSpellingCorrectForText(this.text);
   }
}

As you can see in the example above the spellchecking responsibility is delegated to an external dependency which is injected in the constructor. The TextEditor does not need to know how to spellcheck, he just calls an interface with a method.

Why do we do this? To respect SOLID (SRP): https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

More here: https://softwareengineering.stackexchange.com/questions/135971/when-is-it-not-appropriate-to-use-the-dependency-injection-pattern http://www.tutorialspoint.com/spring/spring_dependency_injection.htm

Upvotes: 0

Pritam Banerjee
Pritam Banerjee

Reputation: 18958

It is an example of DI. You do it here :

Employee emp1 = new Employee("John", "ABC");
Application app1 = new Application(emp1);

You implement it here :

 public Application(Employee emp){
    this.emp = emp;
}

This kind of DI is known as constructor injection.

Had you had a setter of employee in your application class, and had you set the employee with that setter, then it would have been called setter injection

Upvotes: 1

David
David

Reputation: 219047

You are successfully injecting a dependency here:

Employee emp1 = new Employee("John", "ABC");
Application app1 = new Application(emp1);

Insomuch as the instance of Application requires an instance of Employee, and therefore advertises on its constructor that one must be supplied. This is a textbook example of inverting that dependency. (Or, simplified, "Require, don't instantiate.")

However, how you store that dependency is a bit questionable:

private static Employee emp;

In the example provided this likely won't cause any problems. But what happens when you need to create another instance of Application which needs another dependency instance of Employee? That second instance would be overwriting the first and breaking its dependency.

If the instance needs the dependency, then the instance should store the dependency:

private Employee emp;

(Might even make it final as well, unless you have reason to ever change it during the life of the instance.)

Granted, the semantics of the name Application implies that there would only ever be one instance. But a singleton instance would likely be a better approach than static members in that case. As a general rule of thumb in object-oriented programming, be somewhat judicious of your use of static members. They have their use, but they very easily have their mis-use as well.

Upvotes: 3

Related Questions