I have a class I call my Dispatcher and when its dispatch() method is run it instantiates the requested controller.
My AbstractController has a constructor like
public function __construct(RequestInterface $request, ResponseInterface $response, ViewFactory $viewFactory, ServiceFactory $serviceFactory)
As you can see my controllers have 4 dependencies.
At the moment when I instantiate my Dispatcher I inject the ViewFactory and ServiceFactory into its constructor and then when I run the dispatch() method I supply the Request and Response objects as arguments and I can then inject all four dependencies into my controller.
Would it be better to just supply all the controllers dependencies when calling the dispatch() method or supply them all in the constructor of the Dispatcher and then run a dispatch() method with no arguments or is there a better way overall?
You have 4 dependencies you want to inject in a new controller instance, 2 have a request/response life cycle and 2 have a longer life cycle (process?), before invoking some method on it. I would separate the creation of the controller from the invoking by creating a controller factory.
The controller factory would instantiate a controller using a method that receives only the request and reponse objects as parameters. The factory would be aware of the life cycle of the two longer lifed dependencies, perhaps share the same life cycle. The factory's user is then free to invoke any method they would like on the (abstract) controller returned. This is more flexible than the delegation pattern you propose. You could of course still use delegation, but then I would probably still have the Dispatcher only do dispatching and leave object creation to a factory.
Of course, there is no right answer with these kind of questions. It all depends on a lot of factors (requirements, size of codebase, the project, etc). Hope this helps though. Good luck!
Here is a rule of thumb that I use when design API: if your class has 3+ dependencies, it is doing too much.
The dependencies that you pass in the constructor, should be mandatory for your instance to function. In your case, you have a controller there. Controllers repsonsibilities are as follows:
A controller can send commands to its associated view to change the view's presentation of the model. It can also send commands to the model to update the model's state. source: wikipedia
Controllers should not be responsible for creation or rendering of the view instance.
I am not sure what is the role of the Dispatcher instances, but they should not be dealing with creation logic itself. What you essentially end up with here is a mix of possible LoD violation and a definite SRP violation.
The creation logic should be segregate to factories and builders. This way would also let you decouple your Dispatcher instances from the footprint of controller's constructor. Currently, if you introduced a different subclass of controllers, with different set of dependencies, you would also need to change the Dispatcher implementation.
As for "how to make a factory", you can find a simplified example here.