From apprentice to Artisan translation 04

Reflect Resolution Reflection Solution

One of the most powerful features of the Laravel container are its ability to automatically resolve dependencies via Reflec tion. Reflection is the ability to inspect a classes and methods. For example, the PHP ReflectionClass class allows-inspect the method avaliable on a given class. The PHP method method_exists is also a form of reflection. To play with PHP's reflection class, try the followring code on one of the Your classes:

Using reflection to automatically process dependencies is one of the most powerful features of the Laravel container. Reflection is the ability to probe classes and methods at run time. For example, PHP ReflectionClass can detect a method of a class. method_existsin a sense, it is also a reflection. Let's play with the PHP reflection class and try the following code (Stripebiller for your own defined Class):

$reflection = new Reflectionclass (' Stripebiller '); Var_dump ($reflection->getmethods ()); Var_dump ($reflection- >getconstants ());

By leveraging this powerful feature of PHP, the Laravel IoC container can do some interesting things! For instance, consider the following class:

Thanks to this powerful PHP feature, Laravel's IOC container can be a fun feature! Consider the following class:

Class Usercontroller extends basecontroller{public    function __construct (stripbiller $biller)    {        $this- >biller = $biller;    }}

Note that the controller is type-hinting the StripBiller class. We is able to retrieve this type-hint using reflection. When the Laravel container does not has a resolver for a class explictity bound, it would try to resolve the class via ref Lection. The flow looks like this:

Note that the constructor of this controller implies that there is a StripBiller type of parameter. This type hint can be detected using reflection. When the Laravel container does not resolve a type of apparent binding, the container will try to resolve it using reflection. The program flow is similar to this:

1. Do I had a resolver for Stripbiller?

   Already have a stripbiller binding?

2. No resolver? Reflect into Stripbiller to determin if it has dependencies.

   Not tied? Then use reflection to detect Stripbiller. See what he needs to rely on.

3. Resolve any dependencies needed by Stripbiller (recursive).

   Resolve all dependencies required by Stripbiller (recursive processing)

4. Instantiate new Stripbiller instance via Reflectionclass->newinstanceargs ().

   Use ReflectionClass->newInstanceArgs() to instantiate Stripbiller

As can see, the container are doing a lot of heavy lifting for you, which saves if you have to write resolves for E Very single one of your classes. This is one of the most powerful and unique features of the Laravel container, and has a strong grasp of this capabilit Y is very beneficial when building large Laravel applications.

As you can see, the container has done a lot of heavy work for us, which will save you the hassle of writing a lot of bindings. This is the most powerful and unique feature of the Laravel container. Mastering this ability is very useful for building large-scale laravel applications.

Now, let's modify our controller a bit. What if it looks like this?

Let's change the controller and change it so what happens?

Class Usercontroller extends basecontroller{public    function __construct (billerinterface $biller)    {        $ This->biller = $biller;    }}

Assuming we have not explicitly bound a resolver BillerInterface for, how would the container know what class to inject? Remember, interface can ' t be instantiated since they is just contracts. Without us giving the container any more information, it'll be unable to instantiate this dependency. We need to specify a class that should is used as the default implementation of this interface, and we could do so via the c1/> Method:

Suppose we don't have to BillerInterface do any binding, how does the container know what class to inject? You know, interface can't be instantiated, because it's just a convention. If we do not provide more information, the container cannot instantiate this dependency. We need to explicitly indicate which class to implement this interface, which requires a bind method:

App::bind (' Billerinterface ', ' Stripbiller ');

Here, we is passing a string instead of a Closure, and this string tells the container to always use the StripBiller class Anyt IME it needs an implementation of the BillerInterface interface. Again, we ' re gaining the ability to switch implementations of services with a simple one-line change to our container bind Ing. For example, if we need to switch to Balanced Payments as our billing provider, we simply write a new BalancedBiller implementation BillerInterfaceof, and change our container binding:

Here we only pass a string in, not an anonymous function. This string tells the container to always use it StripBiller as BillerInterface the implementation class. In addition, we have the ability to easily change the implementation by just changing one line of code. For example, suppose we need to switch to balanced payments as our payment provider, we just need to write a new one BalancedBiller to implement BillerInterface the interface, and then modify the container code:

App::bind (' Billerinterface ', ' Balancedbiller ');

automatically, our new implementation'll be used throughout out application!

Our app is loaded with the new payment implementation code!

When binding implementations to interfaces, your may also use the singleton method so the container only instantiates one Insta nCE of the class per request cycle:

You can also use singleton methods to implement singleton patterns.

App::singleton (' Billerinterface ', ' Stripbiller ');

Master the Container master container

Want to learn even more about the container? Read through its source! The container is only one class: Illuminate\Container\Container . Read over the source code to gain a deeper understanding of the container works under the hood.

Want to learn more about containers? To read the source code! The container has only one class Illuminate\Container\Container . You'll have a better understanding of the container when you're done reading it.

From apprentice to Artisan translation 04