Design note: why EK9 limits injection and aspects
This note goes with Dependency Injection in EK9. If you have used Spring or AspectJ with Java, you may find what EK9 offers inadequate. It is meant to be small.
What EK9 leaves out
- Injection of anything but a component. Only an abstract base component can be injected.
- Detail in an aspect. An aspect sees the component name and the method name, as text. It does not see the parameters.
- Filtering. You cannot apply an aspect to some methods of a component and not others; that is too fragile.
Why
Other aspect oriented programming solutions give a little too much detail. That looks like a good idea at first, but it tempts developers to alter processing in the aspect. That leads to defects that are very hard to identify and resolve. Anything beyond the bare fact that a method was called tends to lead to complexity, confusion and brittle code that fails when refactored.
Injection has a similar cost. Used heavily, it causes 'hidden' coupling: a component injected inside a method is invisible from outside the class, so the class is less portable, harder to refactor and less reusable, and it cannot be pure. Passing a component in as a parameter keeps the dependency visible.
Opinionated, by experience
Some developers will consider this a bad thing: developers should have the freedom to do what they want. You can, but not in EK9; use Java and Spring if that meets your needs.
EK9 is opinionated. It provides more in some areas and less in others, and this is born of experience: of having to deal with the nightmares of injection, tight coupling and hidden dependencies.
So the application construct is for the high-level composition of a solution. Invert control by passing instances in at construction, and use dependency injection only when you need it.