Java Dependency Injection – Difference Between Efferent Coupling and Dependency Injection

dependency-injectionjava

I am working on research that analyzes dependency injection (DI) in Java projects. The more I read, the more I get confused by DI in relation to other frameworks and even software quality metrics.

I have been recently reading about afferent couplings (Ca), efferent couplings (Ce), and instability (I) with the formula below proposed by Martin Fowler:

I = (Ce/(Ce + Ca))

I noticed that the definition of efferent couplings is that it counts the number of classes the current class depends on. Is that essentially the same as dependency injection definition-wise, or are there more nuances to what is considered a dependency that has the DI framework as opposed to simply a class that the current class depends on?

Best Answer

They are different things.

(efferent) Coupling refers to classes your code won't compile without.

Dependency Injection is a way of passing in references to a class.

class Dog
{
   List<Leg> Legs {get;set;}
}

Dog is coupled to Leg

class Dog
{
   Dog(LegBuilder lb)
   {
       this.LegBuilder = lb
   }
   List<Leg> Legs {get;set;}
}

new Dog(legBuilder);//injecting the required legbuilder class

Dog Is coupled to Leg and LegBuilder, and we are injecting a LegBuilder

Related Solutions

Alternatives to Dependency Injection for Stateless Classes in C++

If you donot like the additional constructor arguments for the dependencies you need a DI-Container to handle the instance creation for you.

You can use either an existing di-container framework or implement a poor mans version on your own

public PoorMansDiContainer : IPoorMansDiContainer {
    private IService mService = null;
    private IFooService mFooService = null;

    public IService getSingletonService() {
        if (mService == null) {
            mService = new ServiceImpl(getSingletonFooService());
        }
        return mService;
    }
    public IFooService getSingletonFooService() {
        if (mFooService == null) {
            mFooService = new FooServiceImpl();
        }
        return mFooService;
    }
}

C# – Dependency injection for a library with internal dependencies

In the web site's composition root, they just need to register the default repository locator

IMO the web site doesn't even need to know about your repositories. As you said, the repos and vendors classes are internal, so your site should not worry about accessing them or injecting them into somewhere. Again, as you said, it is your library's role to abstract multiple vendors and expose a simpler API to the user (which is the web site in your example).

Having said that, I think you should:

In your API, provide some initial entry point method, that needs to be executed once by the client in order that your library works appropriately;
Within this method (that's within your library), you configure the container with vendors repositories classes (internal to your library);
Keep vendors stuff private and your services public
That's it: your client (the website) need to worry only about injecting your services, nothing more than that.
Optional: you could use configuration file to bind interfaces and implementations

About your question / worries:

You (usually) have no control about what your client will do; the client app might not even inject your classes, it could just use them right away; so don't worry about that, like said in the comments;
Config file might be a better approach for this, easily changeble for production or test environments;
Regarding unit testing purposes, I see no problem with this attribute;
My suggestion solves this

Best Answer

Related Solutions

Alternatives to Dependency Injection for Stateless Classes in C++

C# – Dependency injection for a library with internal dependencies

Related Topic