Can I call this a dependency injection?

Question

I am new to dependency injection and I am trying to figure it out. Lets say I have class book :

class Book
{
    public String Author { get; set; }
    public String Title { get; set; }
    private int Quantity {get;set;}

    public Book(String aut, String pav, int qua)
    {
        this.Author = aut;
        this.Title = pav;
        this.Quantity = qua;
    }
}

and then other class book with type

class BookWithType
{
    public Book Book { get; set; }
    public String Type { get; set; }

    public BookWithType(Book book, String type)
    {
        this.Book = book;
        this.Type = type;
    }
 }

Can I say that this is a dependency injection when in BookWithType constructor I inject Book object?

Yes, or call it composition. Or is `Book` class also using DI because you inject the author into it using constructor injection? In my opinion DI is about injecting services. The `Book` and `BookWithType` classes on the other hand are data models. — Dirk, Nov 11 '14 at 12:00
I have to use DI for my project and I am working on how to do that — uvytautas, Nov 11 '14 at 15:55

score 2 · Accepted Answer · edited Nov 11 '14 at 17:39

2

You wouldn't create a dependency injection with a data transfer object. It would be more like:

public class Book
{
    public String Author { get; set; }
    public String Title { get; set; }
    public int Pages {get;set;}
    public string Type {get;set;}

    public Book(String aut, String pav, int pages, string type)
    {
        this.Author = aut;
        this.Title = pav;
        this.Pages = pages;
        this.Type = type;
    }
}

Then some kind of display layer like:

public class BookView
{
    private IBookRetriever _bookRetriever;

    public BookWithType(IBookRetriever bookRetriever)
    {
        _bookRetriever = bookRetriever;
    }
    public Book GetBookWithType(string type) {
        return _bookRetriever.GetBookOfType(type);
    }
}

Where IBookRetriever...

public interface IBookRetriever {
    Book GetBookOfType(string type);
}

edited Nov 11 '14 at 17:39

C Bauer

5,003
4
33
62

answered Nov 11 '14 at 11:40

Christos

53,228
8
76
108

Could the downvoter explain me please where I am wrong? Thank you in advance. – Christos Nov 11 '14 at 16:20
1

This answer gives the questioner a wrong view of Dependency Injection, because it implies that Dependency Injection only works with abstractions. Furthermore the answer tends to create interfaces for DTOs, which is not always necessary. – Rookian Nov 11 '14 at 16:21
1

@Rookian I agree with you that's not the best example on explaining Dependency Injetion. However, I should show an exmaple similar to the posted code. Furthermore, if we don't use abstractions, I don' think that will get the full benefits of DI. How we will mock our dependencies in case of unit testing. If we were using concrete objects the unit testing would have been more difficult than using abstractions. Isn't that correct? In no way, I suggest we create interfaces for DTOs. – Christos Nov 11 '14 at 16:24
If we inject a concrete object in form of a DTO like Book, then we can just set up the necessary properties. So no need for an interface. Whereas if we have a service that depends on a not controllable dependency like the file system, then we should inject an abstraction. – Rookian Nov 11 '14 at 16:32
@Rookian I agree with you 100%, but as I commented before, I tried to give an example relative to the OP. I know it's not the correct case. Since I see that my answer creates too much confusion for getting to downvotes in the row, I will try to update it later. – Christos Nov 11 '14 at 16:35

score 1 · Answer 2 · answered Nov 11 '14 at 12:13

The point of Dependency injection pattern is to create loosely coupled components without concrete dependencies on other components. So, what's wrong with using concrete implementations directly? Well, problem is that in future it could be difficult to support such systems. On the contrary, when you have loosely coupled classes, it's very easy to change their behaviour: you just need to provide another implementation of abstraction.

Christos gave your nice example of doing it. Your BookWithType class no longer depends on concrete Book, instead it depends on IBook abstraction. So, you could provide different implementation of IBook if needed. But you, probably, would not see the full power of using DI from this example, because it's rather simplified. Instead of this, imaging huge system with hundreds of components bonded together: how to fight complexity there? The answer is to use best programming practices, and DI is one on the top of them.

And most importantly, with loosely-coupled components you would get highly-testable system, where to write unit-tests is a pleasure: you could easily provide mocks/stubs etc instead of concrete implementations.

So, the answer on your question is "NO". You can't call this a dependency injection(within the meaning of "DI" pattern).

Can I call this a dependency injection?

2 Answers2