Inversion of Control (IoC) container focusing on Constructor Inject with support for automatic assembly, typed and non-typed constructor dependencies, circular references detection, multiple repository locations and hierarchical containers.
Inversion of Control is a common pattern that helps assemble components into a cohesive application.
In Padrino, you declare your class dependencies in your constructor as arguments like you normally do and, when requesting for a new instance of your class, it is automatically satisfied. This mechanism is not limited to the constructor. For exemple, the library Pop Dispatcher use it to fill method arguments in a richer way than "call_user_func" would otherwise do.
Padrino will save you lines of code to write and maintain by naturally assembling your code into a cohesive architecture. When your application is small, it is quite easy to initialize all the required components of your application, but with time, you want to make sure your components are in the right state and only loaded when you need them. Also, refectoring your code in order to add more complexity may become tricky. With Inversion of Control, you won't have to deal with those concerns. The more your application grows, the more you'll benefit of Padrino.
The components need to be constructed with all their dependencies in the correct order as declared in the constructor.
@code php // ... initialise rum dependencies $rum = new Rum($sugarcane, $fermentation, $distillation); // ... more dependency initialisation $tiramisu = new Tiramisu($cooky, $mascarpone, $egg, $suggar, $coffee, $rum);
@code php $padrino = new Padrino(); $tiramisu = $padrino->Tiramisu;
- Code is naturally structured into separated components
- Components facilitates reuse and improvement over time
- Unit Testing is simplified and the writing of mock object easy to inject on classes initialization
- Understandable architecture replace nest of singletons
- Multiple instance of an application can be run in a same request
- Flexibility by easily switching from an implementation to another
- Less boilerplate code
Those are interchangeable words. Asking ten developers what a component is and we'll get 10 definitions and synonyms.
In general, we tend to call a component a combination of a contract (the interface, what a class is meant to do) and its inner working (the implementation, how it fill the contract). A service is more focusing on the contract. A dependency is a component required by an other component.