Responsibility of getInstance() on service container?

[rschoonheim]

Hello Folks,

I'm new here! Trying to write politely. English isn’t my first language, sorry. Feedback is welcome😄.

I was debugging the Laravel service container. It’s pretty awesome in my opinion :D. I have a little question about the getInstance() method on Illuminate\Container\Container::class.

Currently it initializes an instance of Illuminate\Container\Container::class when Illuminate\Container\Container::$instance equals null. Why? In my opinion, is getInstance() a getter. Whenever I decide to create a getter it is to expose some data located in the private scope of an object.

I think it’s wrong to make getInstance() responsible for object initialization? Or am I missing some details?

Code

Pull request that makes getInstance() responsible for object initialization

    /**
     * Get the globally available instance of the container.
     *
     * @return ?|static
     */
    public static function getInstance()
    {
        if (is_null(static::$instance)) {
            static::$instance = new static;
        }

        return static::$instance;
    }

[dennisprudlo]

This is called a singleton. You can see the property and the function are both static.

We don't want multiple container instances in our application. This methods gives you the single instance or creates it if there isn't one already. Otherwise you would check this every time you want to get the Container instance.

More info: https://en.wikipedia.org/wiki/Singleton_pattern?wprov=sfti1

[rschoonheim]

Hi Dennis,

Thanks for responding! Thanks for providing me additional information about the singleton pattern. I am quite familiar with singleton (: I am unfamiliar with how it’s implemented within the container. I did some additional research after refreshing my knowledge of the singleton pattern.

I’m not sure if I’m on the right track, probably missing something! When Laravel gets booted an instance of Illuminate\Foundation\Application::class will be created. The application class is an extension of \Illuminate\Container\Container::class making it the service container.

The service container is singleton to make registered “entries” available for the whole application. When creating multiple containers it will become extremely hard to manage all of the responsibilities from the service container.

Within the code base I see multiple references directly to the service container, why?

Take a look at Illuminate\Queue\Capsule::class in the constructor method for example. I think the level of coupling is quite high. The $container argument must be an instance of \Illuminate\Container\Container::class while the setup container method expects \Illuminate\Contracts\Container\Container:class. \Illuminate\Contracts\Container\Container seems logical to me. On line 33 an instance of \Illuminate\Container\Container::class will be created when $container equals null.

But $container must be an instance of \Illuminate\Container\Container::class . Am I missing something?

[rschoonheim]

Nevermind, found the missing bits. Thanks!