Other dependency injectors

[auburus]

First of all, let me say I really like Auryn since you made me discover it.

But, I've been learning these past months about DI and containers and all that stuff, and I don't really think that other DI containers fall in the service locator antipattern, as pointed out here.

So, as far as I understand, getting the constructor arguments from the container is not a bad practice. The antipattern would be passing the container as a constructor argument, and using it inside the class.

Am I mistaken, or there is something I still don't understand?

Thanks

[Zvax]

Hello,

I don't want to speak out of place, but I'm not sure what you actually expect. Do you mean that you'd like the part about DI to be rephrased to be more inclusive of other DIC's?

Since it really is an opinionated statement, and disclosed as such, I don't think it's really wrong to leave it as is.

If what you wish for is a greater understanding of DI in general and of why other DIC's are considered as service locators, I'm not sure this is within the scope of this tutorial. IMO, the fastest way to understand the difference between Auryn and other DIC's is to actually use them extensively, and compare the ease of use and configuration.

Unless you have a different statement that would actually put in light a problem, I think this issue could be closed.

Cheers

[auburus]

Hi,

It's the second case that you have mentioned. So, I've read all the tutorial and the only thing which wasn't entire clear from my point of view was why you asserted that the others where doing it "wrong".

So, I hope that, although it may be beyond the scope of the tutorial, if you could just paste some other blog post or article which explains further on that, just for the curious reader as myself, that would be great. I promise you I've been reading comparisons on them, and I haven't found anything that discredits the others as your tutorial "suggests", thats the only thing I'm worried about.

But, of course, if you find that this will create more problems than solutions, it's your tutorial and I have really learned a lot from it, so whatever is your decision would be fine.

[HassanAlthaf]

@auburus You can learn everything about IOC here: https://en.wikipedia.org/wiki/Inversion_of_control

To achieve DI, we use IoC (Inversion of Control) as explained here: https://en.wikipedia.org/wiki/Dependency_injection

Why do we want to achieve DI?

It is because we want to write SOLID code. The principle 'D', 'Dependency Inversion Principle' can be achieved easily through Dependency Injection and IoC. How?

Lets take Auryn for example.

We have a class that accesses a data store and we want to abstract the data store out.

class FetchDataFromADataStoreClass 
{
    private $driver;

    public function __construct(DataStoreAccessDriver $driver)
    {
        $this->driver = $driver;
    }
}

In the above code, we abstract out our driver with an interface DataStoreAccessDriver which would be implemented by maybe a MySQLDriver or an APIDriver. In here, if we ever wanted to change our access driver, we can so without altering any code. All we do is change the alias setup in Auryn for the interface and it will inject the correct class implementing that interface for us.