Question

A simple(and lengthy) question, and not a simple answer. Working with some DI frameworks(Spring, Guice) I came to a conclusion that some of the praxis presented by others is not so simple to implement. I really seem stuck on this level.

I will try to present this as simple as possible, even though some of the details will probably be lost. I hope the question will be clear.

Say I have a StringValidator, a simple class with a responsibility to validate strings.

package test;

import java.util.ArrayList;
import java.util.List;

public class StringValidator {
    private final List<String> stringList;
    private final List<String> validationList;

    private final List<String> validatedList = new ArrayList<String>();

    public StringValidator(final List<String> stringList, final List<String> validationList) {
        this.stringList = stringList;
        this.validationList = validationList;
    }

    public void validate() {
        for (String currentString : stringList) {
            for (String currentValidation : validationList) {
                if (currentString.equalsIgnoreCase(currentValidation)) {
                    validatedList.add(currentString);
                }
            }
        }
    }

    public List<String> getValidatedList() {
        return validatedList;
    }
}

The dependency is the lowest possible, allowing simple tests like these:

package test;

import org.junit.Assert;
import org.junit.Test;

import java.util.ArrayList;
import java.util.List;

public class StringValidatorTest {
    @Test
    public void testValidate() throws Exception {
        //Before
        List<String> stringList = new ArrayList<String>();
        stringList.add("FILE1.txt");
        stringList.add("FILE2.txt");

        final List<String> validationList = new ArrayList<String>();
        validationList.add("FILE1.txt");
        validationList.add("FILE20.txt");

        final StringValidator stringValidator = new StringValidator(stringList, validationList);

        //When
        stringValidator.validate();

        //Then
        Assert.assertEquals(1, stringValidator.getValidatedList().size());
        Assert.assertEquals("FILE1.txt", stringValidator.getValidatedList().get(0));
    }
}

If we wanted to increase the flexibility even more, we could use Collection<> instead of List<>, but let’s presume that that won’t be necessary.

The classes that create the lists are the following(use any other interface standard):

package test;

import java.util.List;

public interface Stringable {
    List<String> getStringList();
}

package test;

import java.util.ArrayList;
import java.util.List;

public class StringService implements Stringable {

    private List<String> stringList = new ArrayList<String>();

    public StringService() {
        createList();
    }

    //Simplified
    private void createList() {
        stringList.add("FILE1.txt");
        stringList.add("FILE1.dat");
        stringList.add("FILE1.pdf");
        stringList.add("FILE1.rdf");
    }

    @Override
    public List<String> getStringList() {
        return stringList;
    }
}

And:

package test;

import java.util.List;

public interface Validateable {
    List<String> getValidationList();
}

package test;

import java.util.ArrayList;
import java.util.List;

public class ValidationService implements Validateable {

    private final List<String> validationList = new ArrayList<String>();

    public ValidationService() {
        createList();
    }

    //Simplified...
    private void createList() {
        validationList.add("FILE1.txt");
        validationList.add("FILE2.txt");
        validationList.add("FILE3.txt");
        validationList.add("FILE4.txt");
    }

    @Override
    public List<String> getValidationList() {
        return validationList;
    }
}

And we have a Main class with a main method:

package test;

import java.util.List;

public class Main {
    public static void main(String[] args) {
        Validateable validateable = new ValidationService();
        final List<String> validationList = validateable.getValidationList();

        Stringable stringable = new StringService();
        final List<String> stringList = stringable.getStringList();

        //DI
        StringValidator stringValidator = new StringValidator(stringList, validationList);
        stringValidator.validate();

        //Result list
        final List<String> validatedList = stringValidator.getValidatedList();
    }
}

So let’s say that the classes generate the lists in runtime(when the user wants to).
The “direct”(static) binding is impossible.

If we want to provide the lowest possible coupling, we would use the lists to provide us with data required to run the validation(StringValidator).

BUT, if we want to use the container to help us with the “glue code”, we could inject the two “services” into the StringValidator. That would provide us with the correct data, but at the cost of COUPLING. Also, StringValidator would have the extra responsibility of actually calling the dependencies.

If I use delegation in that way, I clutter my code with unwanted responsibilites(not something I want).

If I don’t, I don’t see a way in wich this could work(Provider could provide me with the correct lists, but, again, the dependency is there).

The more generic question is – is there a way to actually create a completly decoupled application using DI frameworks, or is this some sort of an ideal?
In wich situations do you use the DI framework, in wich you don’t?
Are DI frameworks really the “new new”?

Thank you.

Answer 1

I finally think I got it! Sorry for the lack of information in my question. Ryan Stewart wrote “There’s no reason your “stringList” and “validationList” can’t be managed by a DI container and injected into your StringValidator.”, and maybe he had this in mind. If you did, than that was the answer I was looking for, and your answer is correct, so thank you. I found it myself by experimenting in Spring.

If I use the classes that contain the lists, than the resulting class cannot recive the lists. They are dynamically created, and I saw no way to bring them to StringValidator. Dynamically means – without the control of the container.

The only way I could have injeted them was to inject them directly into StringValidator.

But I forgot one thing. Spring is much more flexibile(based on my experience) – I frankly don’t know how I could have solved this in Guice(haven’t really tried, maybe I’ll give it a go).

Why not create the list dynamically, and use that list in the container life as a list that can be used to inject the required class?

The point being, when the container initializes the list:

package test;

import org.springframework.stereotype.Component;

import java.util.ArrayList;

@Component
public class StringList extends ArrayList<String> {
}

package test;

import org.springframework.stereotype.Component;

import java.util.ArrayList;

@Component
public class ValidationList extends ArrayList<String> {
}

Or if you prefer the xml way(commented):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:context="http://www.springframework.org/schema/context" xmlns:jee="http://www.springframework.org/schema/jee" xmlns:tx="http://www.springframework.org/schema/tx" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.1.xsd         http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd         http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd         http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-3.1.xsd         http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.1.xsd">
    <context:component-scan base-package="test"/>

    <!--<bean id="validationList" class="java.util.ArrayList" scope="singleton"/>-->
    <!--<bean id="stringList" class="java.util.ArrayList" scope="singleton"/>-->
</beans>

That list can be used throught the life of the container, thus the application.

package test;

import org.springframework.stereotype.Component;

import javax.inject.Inject;
import java.util.ArrayList;
import java.util.List;

@Component
public class StringService implements Stringable {

    private List<String> stringList;

    @Inject
    public StringService(final ArrayList<String> stringList) {
        this.stringList = stringList;
        createList();
    }

    //Simplified
    private void createList() {
        stringList.add("FILE1.txt");
        stringList.add("FILE1.dat");
        stringList.add("FILE1.pdf");
        stringList.add("FILE1.rdf");
    }

    @Override
    public List<String> getStringList() {
        return stringList;
    }
}

package test;

import org.springframework.stereotype.Component;

import javax.inject.Inject;
import java.util.ArrayList;
import java.util.List;

@Component
public class ValidationService implements Validateable {

    private List<String> validationList;

    @Inject
    public ValidationService(final ArrayList<String> validationList) {
        this.validationList = validationList;
        createList();
    }

    //Simplified...
    private void createList() {
        validationList.add("FILE1.txt");
        validationList.add("FILE2.txt");
        validationList.add("FILE3.txt");
        validationList.add("FILE4.txt");
    }

    @Override
    public List<String> getValidationList() {
        return validationList;
    }
}

And, I don’t have to worry about the services, because the lists are now in the container, living their own lifecycle, thus available every time i request them.

package test;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

import java.util.ArrayList;
import java.util.List;

@Component
public class StringValidator {
    private List<String> stringList;
    private List<String> validationList;

    private final List<String> validatedList = new ArrayList<String>();

    @Autowired
    public StringValidator(final ArrayList<String> stringList,
                           final ArrayList<String> validationList) {
        this.stringList = stringList;
        this.validationList = validationList;
    }

    public void validate() {
        for (String currentString : stringList) {
            for (String currentValidation : validationList) {
                if (currentString.equalsIgnoreCase(currentValidation)) {
                    validatedList.add(currentString);
                }
            }
        }
    }

    public List<String> getValidatedList() {
        return validatedList;
    }
}

The answer actually looks very simple, but it took me some time before I could get here.

So, the Main class looks like this, and everything is handeled by the container.

package test;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.stereotype.Component;

import java.util.List;

@Component
public class Main {
    @Autowired
    private StringValidator stringValidator;

    public void main() {
        stringValidator.validate();
        final List<String> validatedList = stringValidator.getValidatedList();
        for (String currentValid : validatedList) {
            System.out.println(currentValid);
        }
    }

    public static void main(String[] args) {
        ApplicationContext container = new ClassPathXmlApplicationContext("/META-INF/spring/applicationContext.xml");
        container.getBean(Main.class).main();
    }
}

It seems possible. So to recap the answer – you could always have the dynamically created class in the container, and a pretty good decoupleing!