Handlers and Services

Handlers and Services are two distinct concepts, but they were designed together and are being used together. Specifically, services make use of handlers. Handlers, however, can be freely used in other contexts as well.

Handlers are storable objects that also implement a get_type method. For example, handlers for the logging service are of the logging type.

Services are meant to be central hubs (i.e., singleton instances) for performing certain actions. It's not mandatory, but we designed all of our services to delegate the responsibility of performing the actions to a handler. For example, a service inheriting the AbstractHandlerService class always performs the actions with the same handler whereas a service inheriting the AbstractMultiHandlerService class needs to be instructed which registered handler to use.

Handlers are not meant to be used directly. An object usually has one-or-more registered handlers that it can perform actions with. That's why the HandlerAwareInterface (and the corresponding trait) and the MultiHandlerAwareInterface (and the corresponding trait) are very important.

The handlers are also prime candidates for extension action traits. There are 3 traits that the foundations module comes with:

• OutputHandlersTrait -- using objects will call the output method of their registered handlers.

• RunHandlersTrait -- using objects will call the run method of their registered handlers

• ResetHandlersTrait -- using objects will call the reset method of their registered handlers.

For example, a multi-handler-aware-service implementing the OutputtableInterface and using the OutputHandlersTrait mentioned above will automagically call the output method of all its registered handlers also implementing the OutputtableInterface when the service's own output method is called. Pretty neat, huh?