I'm currently developing a small component-based framework the Android platform. The framework has some ready for use and some abstract (has some internal logic, but the developer needs to add some code to make it fully functional) components. All communication between the components is satisfied using interfaces. My question is:

Knowing that some components have dependencies, my framework should automatically provide them?

E.g.: I have an A component that "needs" B component. At first, I thought of two solutions:

  1. My framework should create and inject the B component automatically when the developer instantiate the component A. If B is an abstract component, I would create and provide a default instance of it.

  2. The framework should explain in the API that A component needs B component and then, leave to the developer to instantiate B component and pass it as a dependency to A.

In the second solution the developer could also create a new component that respects the contract (interfaces) with the A component and then use it.

Which of these solutions would lead to better maintenance, flexibility, and expansion of both the framework and the developers code? I accept other solutions.

  • I don't think solution 1 qualifies as dependency injection. You are doing it, but at the same time removing the advantages of dependency injection, which is to dynamically substitute a type into the system at run-time. Unless I misunderstood. Commented Aug 13, 2015 at 20:25
  • @FrankHileman, all the components communication are done using interfaces, so I think that would be possible to dynamically change components as long as the new component respects the contract. Commented Aug 13, 2015 at 20:36
  • based on your explanation of solution 1, it does not sound like the external developer has a chance to change the data type, or class, which is instantiated. Commented Aug 13, 2015 at 20:38
  • Yes, because in that case it would be given a default component with basic functionality. But that would only happen if the developer wanted to use the standard components and not the modified / created by him . In this case it would be possible to provide this flexibility to the developer ? Commented Aug 13, 2015 at 20:45
  • Yes, but a design can also provide this flexibility without dependency injection. Personally, I have gotten a bit tired of unnecessary dependency injection (i.e., it is always the same class used, and the flexibility is wasted). Commented Aug 13, 2015 at 22:21

1 Answer 1


Do both

If you are making a framework, flexibility is key. Most frameworks provide interfaces and default implementations along with empty constructors wired to defaults, but allow for you to overwrite behavior by passing in your own implementations, or passing in a framework-provided alternative implementation.

public interface IReader { string Read(); }
public interface IWriter { void Write(String str); }

public class DefaultReader: IReader
    public string Read()

public class DefaultWriter: IWriter
    public void Write(String str)
        File.Write("c:\myfile.cnf", str);

public class MyFrameWorkClass
    private IReader reader;
    private IWriter writer;

    public MyFrameWorkClass():
        this(new DefaultReader(), new DefaultWriter())

    public MyFrameWorkClass(IReader reader, IWriter writer)
        this.reader = reader;
        this.writer = writer;

The reason frameworks work this way is simple: they can't provide any DI because that inherently ties them to a DI framework. The only thing they can do (and should do) is provide classes that can be DI'd easily. If you are going for ultimate flexibility, the above code would also have public properties that can be assigned. That way, any DI-framework can be plugged in and use the framework with either constructor-based or property-based injection.

If you want to provide an amount of DI out-of-the-box for your objects, you'll need to create separate components that do the binding for your framework. For example, if I were using Castle Windsor for DI I would provide an Installer-class that can be plugged in.

  • Doing it this way , I could use the delegation pattern to allow the developer to use MyFrameworkClass and also provide his own implementations of IReader and IWriter interfaces. Or if he want, create his own class that does specific things but still implements IReader and IWriter. Am I right? Commented Aug 14, 2015 at 13:59
  • Yes, you can do that.
    – JDT
    Commented Aug 15, 2015 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.