RubenVerborgh
commented
5 years ago It's not clear how the
LdpHandlerwould know whichOperations to create when given anOperationFactory
That's actually the point of the OperationFactory. The LdpHandler does not know which Operation to create; it delegates that knowledge to the OperationFactory. That way, LdpHandler only needs the handling logic that is common between all operations. The idea is separation of concerns.
You can see that idea in action here (slightly different naming):
- https://github.com/RubenVerborgh/solid-server-ts/blob/a93717ec02389ba10c79975fc2bbdbe8d18336f0/src/http/ResourceStoreRequestHandler.ts#L116 does not even know what HTTP methods or corresponding LDP operations exist. So its logic can be tested independently of that; and other implementations of such operations can be added without even touching this class.
- https://github.com/RubenVerborgh/solid-server-ts/blob/master/src/ldp/operations/LdpOperationFactory.ts knows how to pick the right operation. The current code is trivial, but can be tested independently. If operation selection becomes more complex (and it might, since we have extension plans in that direction), only this simple component of code is affected. Moreover, different implementations can be supplied to the handler if different behavior is desired.
In summary, because LdpHandler does not know this, this knowledge can be tested separately and changed at any time, without involving LdpHandler. This is managing complexity through components.
so why not just create the
Operations before you create theLdpHandler
In this architecture, as can be seen in the OperationFactory interface's createOperation method signature, operations are short-lived objects that are created per request. Hence, they cannot be created before LdpHandler.
It's not clear how the
LdpHandlerwould know whichOperations to create when given anOperationFactory, so why not just create theOperations before you create theLdpHandler, and then pass anArrayof those already instantiatedOperations to it instead?