Handling many services ====================== :Published at: March 17, 2020 :Author: Erlend ter Maat :Tags: Drupal, Dependency injection, Maintainable code ---- In my `previous blog post `_ I explained a feature that is introduced in Drupal 8: Dependency injection. There is no limit in the number of services you can make another service dependent of. This may lead to long lists of services. It can become hard to understand the business case that this implemented by the service/form/plugin/whatever. This is where the class resolver can be useful. A working example of the principles in this blog post is available `here `_. Below I show small snippets of the code that you can find in this repo. Organize services in custom forms --------------------------------- Code where you are easily tempted to write one or more very large functions is when creating forms. Next example shows how you can keep code readable. .. code-block:: php class CustomMultistepForm extends FormBase { public static function create(Container $container) { return new static( $container->get('class_resolver'), $container->get('tempstore.private') ); } protected $classResolver; protected $tempStore; public function __construct(ClassResolverInterface $classResolver PrivateTempStoreFacory $tempStoreFactory) { $this->classResolver = $classResolver; $this->tempStore = $tempStoreFactory->get(static::class); } } The form we are building stores its context in a private tempstore. I found in this a better way of storing form data over subsequent web requests. I had issues with storing data on the FormState, and storing data in an object that is intended for storing session data temporally seems a better practice. .. code-block:: php public function buildForm(array $form, FormStateInterface $form_state) { $builder = $this->getPageBuilder(); // Use the builder to populate the $form array. // ... return $form; } protected function getPageBuilder() { switch($this->tempStore->get('current_page')) { default: case CustomStep1FormBuilder::ID: return $this->classResolver->getInstanceFromDefinition( CustomStep1FormBuilder::class ); case CustomStep2FormBuilder::ID: return $this->classResolver->getInstanceFromDefinition( CustomStep2FormBuilder::class ); } } The form is built using a separate class for each page. When a service is only used for one page, the service dependency only has to be defined at the service that uses the dependency. .. code-block:: php class CustomStep1FormBuilder implements CustomFormBuilderInterface { public static function create(ContainerInterface $container) { return new static($container->get('current_user')); } protected $currentUser; public function __construct(AccountProxyInterface $currentUser) { $this->currentUser = $currentUser; } } Conclusion ---------- The class resolver facilitates `the inversion of control principle `_ and, in my opinion, it could be categorized as a way to give your code a `single responsibility `_. Code gets cleaner and more maintainable for when you isolate dependencies from the higher level code, then as little as possible code is required to change when business rules change.