P.JAYASRI
P.JAYASRI

Reputation: 358

Spring Java Object Dependency Injection

i can't understand difference between these two pattern. i feel these two are same but different program patterns. just entered into spring.

pattern 1 - dependency injection by constructor and setter method

class Employee{

   Address address ;

   public Employee(Address address ) {
    this.address = address;
   }
   public void setAddress(Address address ) {
    this.address = address;
   }

}

Pattern 2 - old java object creation

class Employee{
    Address address ;
    public Employee(){
      address = new Address();
    }
}

i can't understand why pattern 1 is good(loosly coupled) and pattern 2 is tightly coupled. anyhow Employee should be depending on Address class .

Upvotes: 0

Views: 830

Answers (3)

Bogdan
Bogdan

Reputation: 24590

Your example is a little bit simple, maybe to simple to catch the full advantages of dependency injection, but the first pattern is better because you decouple your Employe class form the Address.

In this case:

class Employee {
    private Address address ;
    public Employee() {
        address = new Address();
    }
}

your Employee class is responsible for building an Address. It uses new Address(). You are now fixed to this kind of address. If you want to change the address implementation then you need to change the code.

But an address comes in many shapes and sizes. How would you make your Employee work with both an European Address and a Japanese address when you instantiated exactly one type of address in your code?

To make this more clear, let's expand a bit your example and consider Address to be an interface. Programming to an interface is another good practice. So now we have an interface and an implementation:

class Employee {
    private Address address;
    public Employee() {
      address = new JapaneseAddress();
    }
    ...
}

See the problem now? If you later want an European Address you will need to go into the code and make some changes.

If instead you have this:

class Employee {
   private Address address ;

   public Employee(Address address) {
      this.address = address;
   }
   ...
}

you can now inject whatever implementation you like, without touching the code.

Upvotes: 2

kucing_terbang
kucing_terbang

Reputation: 5131

Because if you're using pattern 1, it will be easier if let say you want to add another functionality. The field (which is address in your case) can be easily replaced by another concrete class.

Example, lets imagine that you want to create a logging framework.

Pattern 1

public class LoggingManager {
    private Logger logger;

    public void doLog(String message) {
        logger.log(message);
    }

    //setter getter here 
}

by using pattern 1, you could let ioc container to assign what kind of logging that logging manager will do (it could be log to file or console or probably store the log information into a database and hence, it's loosely coupled).

Pattern 2

public class LoggingManager {
    private Logger logger;

    public LoggingManager() {
        logger = new FileLogger();
    }

    // same method as above
}

as you can see on the snippet, the logging manager will be only capable of doing one thing, log the log information to the file.

Upvotes: 1

prasad vsv
prasad vsv

Reputation: 1168

In the first case, you can send Address class dynamically at runtime (which essentially, dependency injection means) where as in the second case, at the time of coding you might not know what address object needs.

Assume you have a database connection object instead of address object. let us suppose you employee object requires this database object for whatever reasons.

Now if you dont know which database to connect to (you might have to connect to different database, based on the env. prod, dev,qa etc.) second approach doesnot work. where as in the first approach, you can get this configuration from the config files and then send the connection object dynamically at runtime.

Upvotes: 1

Related Questions