### **Booting Providers** ### After all providers have been registered, they are "booted". This will fire the ``boot`` method on each provider. A common mistake when using service providers is attempting to use the services provided by another provider in the ``register`` method. Since, within the ``register`` method, we have no gurantee all other providers have been loaded, the service you are trying to use may not be available yet. So, service provider code that uses other services should always live in the ``boot`` method. The ``register`` method should **only** be used for, you guessed it, registering services with the container. Within the ``boot`` method, you may do whatever you like: register event listeners, include a route file, register filters, or anything else you can imagine. Again, use the provider as organizational tools. Perhaps you wish to group some related event listeners together? Placing them in the ``boot`` method of a service provider would be a great approach! Or, you could include an "events" or "routes" PHP file: ~~~ <!--lang:php--> public function boot() { require_once __DIR__.'/events.php'; require_once __DIR__.'/routes.php'; } ~~~ Now that we've learned about dependency injection and a way to organize our projects around providers, we have a great foundation for building well-architected Laravel applications that are maintainable and testable. Next, we'll explore how Laravel itself uses providers, and how the framework works under the hood! > ### **Don't Box Yourself In** ### > > Remember, don't assume that service providers are something that only packages use. Create your own to help organize your application's services. >