The dependencies service is a multi-handler service with no implemented action methods. The purpose of this service is to provide a unified way of checking whether dependencies are fulfilled or not. It provides the following public methods:
get_dependencies for retrieving a list of dependencies from a given handler
get_missing_dependencies for retrieving a list of missing dependencies from a given handler
are_dependencies_fulfilled for retrieving a list of boolean values determining whether the dependencies of a given handler are fulfilled or not
You must be used by now to the fact that every service has its quirks. In the case of the dependencies service, the quirk is that it has no default handlers because each handler is supposed to be tied to a particular class instance.
At its core, a checker accepts a list of dependencies (each checker might have a different format) and knows how to check whether said dependencies are fulfilled or not. Calling get_missing_dependencies on a checker will return a list of unfulfilled dependencies and calling are_dependencies_fulfilled will return a simple boolean value answering the question.
Continuing with the handlers, the module comes pre-packaged with 2 handlers. The so-called single-checker handler and the so-called multi-checker handler. As their names suggest, the former can store one checker whereas the latter can store multiple checkers. This is a necessary abstraction for supporting the services model.
The difference between the two is that most functions of the single-checker handler will return an array whereas the same functions of the multi-checker handler will return a matrix.
It might come as a surprise to find out the the method are_dependencies_fulfilled of the single-checker handler returns an array with a single entry instead of a simple boolean value. This is done for consistency with the multi-checker handler.
How to use the dependencies service
The dependencies service comes with two traits that try to automagically set things up for you. For example, the InitializeDependenciesHandlersTrait trait lets you define a protected get_dependencies_handlers method inside your class and its output will be automagically registered with the dependencies service on initialization.
Similarly the Dependencies/States namespace contains two traits that let you automagically turn an instance inactive or disabled based on registered dependencies handlers.
Last but not least, the SetupDependenciesAdminNoticesTrait trait goes a step further and will automagically register appropriate admin notices for dependency handlers that influence the activation state of an instance.
Watch out for the SetupDependenciesAdminNoticesTrait trait! It uses the SetupableInactiveTrait which will cause your instance to setup even if inactive. You need to design your code around this.