Closed michielbdejong closed 5 years ago
The last option you wrote is the one 👍 The handler should indeed not instantiate objects; it should not have the knowledge of how to do so.
The code will indeed contain classes (factories), whose sole job is to instantiate others. And the good thing is that such classes could (in time) be fully replaced with configuration. So we could write a JSON(-LD) file explaining which stores to instantiate, and it would just work. (Such dependency frameworks for JS already exist, can assist when we get to that point.)
PS Picked this bit from advice from http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/. One of the articles said something like: there's two kinds of classes, those that do things, and those that create things.
ok, will update + LdpHandler(OperationFactory)
to + LdpHandler(OperationFactory, Authorizer)
.
In general, there will be more constructor parameters than are displayed in the constructor call (cfr. https://github.com/RubenVerborgh/solid-server-ts/blob/1af325bbce3838c818eef0bd8b45955b548e9c67/src/http/ResourceStoreRequestHandler.ts#L31-L39).
I'd suggest to make the constructor argument a hash that can contain multiple parameters. Everything with an aggregation arrow in the diagram will typically be passed in as a parameter (such as TargetExtractor
, multiple BodyParsers
s, etc.)
In the current diagram it looks like the instantiation bootstrap should be:
But then how can the ldpHandler instantiate an Authorizer that uses the same resourceStore as operationFactory?
Should we do:
instead? Or maybe: