artfulrobot
commented
2 years ago I've not read all those, I'd love to one day!
My guilty secret is that I think a lot of these systems over-promise and that in real life, when there's a new/different system that needs to be implemented it's likely to require changes anyway. Like we employ them because we have the foresight to know that in future something will need to change, but unfortunately with hindsight we realise that the thing that changed made the decision about how to provide future flexibility was wrong.
e.g. I love that Civi has api/v3/ directory, because obviously we'll put api4 stuff in api/v4/, right? ...
I think Drupal 8+ went full-on into the DI paradigm. I think the result has been pretty ugly, I abandoned one project after 6 months development! Every new release brought API changes (because we can't foresee what changes will be needed try as we may) and maintaining it became such a cost. Meanwhile, as you point out, developing for it without the IDE being able to comprehend what anything does is a nightmare.
To do anything you need to define it as an abstract contract, implement it in a concrete class, create a service provider class, register all this in a container. Things become so atomised that you can't reason about the bigger business logic. By the end of it it's very hard to locate the actual do-ing code.
The amount of indirections in DI may make application hard to understand. Indirection means code is split and scattered in different places; more indirection makes it more difficult to follow application structure and behavior. (from In defense of service locator)
I think one of the reasons is that the interfaces / contracts change because people choose different products because they offer different features, and they probably do that with different metaphors and structures. In the end, a new cool feature is going to require a tightly coupled set of classes, at least, and possibly some different top-level logic.
Say a competitor/forked collaborator(...) called Doing Community (DC) makes a cool new feature that adds multiple line items to donation pages. Someone using that would need DC specific remote object, mapper, matcher, syncer, and local object classes. All these would be relying on features provided by the others that don't exist in the AN implementation. So these new classes would be tightly coupled and this would need to be configured in the service locator/factory class/some config file. Furthermore, it might require that line items be sync-ed prior to a donation sync, which means a change to the main sync cron jobs.
By the time you've (a) replaced all that code and (b) replaced all the service definitions to use the new code, you're left with loads of classes and it's hard to tell which one is actually being used.
I think refactoring is good when it happens naturally, e.g. oh, I have implemented X and now I need Y. But knowing X well, I can now see the similarities with Y and now I'm in a position to determine how to make the system accommodate X and Y. i.e. the real world concrete different situations are so valuable in informing how to make something flexible. It's hard at the start of something. I feel very much at the start of this project, grappling with a lot of the concepts and it's quite a challenge for me to conceive of more abstraction; but you're more familiar so will be in a better place to do that.
Civi uses Symfony, would it make sense to use that?
True to its form of never quite deciding on something, Civi also involves a combination of DI of the container isntance and static access to it via a facade, Civi::container(). Injecting the container is presumably good because you can have 2 containers :exploding_head: But I've read previously that it's better to inject a service locator, which is basically something that specifies a pre-set list of services (likely from the container), instead of supplying the whole container, since then dependencies are clearer.
At the moment we apply the hard wiring in the static Factory class and the cron job script (which, for example, sets the policy of syncing from remote first - something that might not always be best, depending on lots of factors).
If one civi had to sync some contacts to one system and some to another, a statically bound DI (where the factories are decided at runtime) won't really work, because the context may require different factories. But you could conceive of a runtime services locator being created and passed down. e.g. "I'm the cron job to sync with AN, I will create a SL that builds ActionNetwork\PersonBasic etc. classes and pass that in" (like the remote system is passed in) and "I'm the cron that syncs with DC, I will create a SL that builds DoingCommunity\... objects and pass that down."
What I'm thinking at this moment is that we can still use two approaches: hardwire the parts of the system that seem unlikely to need customization, and use a combination of simple DI/service locator for the parts that need to be customized.
Which parts seem unlikely to need customisation?
Worth remembering that hooks(/event dispatchers and listeners) can also play a useful role.
Bit of a ramble, hope there's something useful in it!
highfalutin
I've been trying to figure out the best way to handle object creation / application component assembly in this project. Examples:
The question I'm grappling with is: where do we want to settle on this spectrum? What's the sweet spot for this project between elegant simplicity/brittleness and powerful flexibility/complexity?
In its current state, the application does different things in different places:
I've been doing a bunch of reading as I try to think through this:
What I'm thinking at this moment is that we can still use two approaches: hardwire the parts of the system that seem unlikely to need customization, and use a combination of simple DI/service locator for the parts that need to be customized.
Identifying exactly which classes are most likely to be customized would be a good next step.