valkyrjaio / valkyrja-java / 31075035100

100%

push

github

[Event] fix: Resolve a dispatched event from the container (#134)

# Description

`EventDispatcher.getEventFromId()` built the event itself. It called
`eventId.getDeclaredConstructor().newInstance()`, and it returned a bare
`new Object()` when the
call failed. `dispatchById()` and `dispatchByIdIfHasListeners()` both
used that method.

The dispatcher therefore decided how every event came into being, and an
application had no way to
state how one of its own events is built. An event that needs a
constructor argument, a shared
instance, or any preparation at all could not be dispatched by id.

The dispatcher already holds a container, and the container is the
framework's own answer to "build
the thing that this identifier names".

[`CONTAINER_BINDINGS.md`](https://github.com/valkyrjaio/architecture/blob/master/CONTAINER_BINDINGS.md)
gives that answer its shape: a binding key, and an explicit factory that
the developer writes. The
dispatcher now asks the container for the binding key, and an
application binds each event that it
dispatches. The Go port already works this way.

## What the dispatcher does now

`getEventFromId()` makes one call: `container.get(eventId, arguments)`.
It then tests the resolved
value against the key, and it passes the arguments to an event that
accepts them.

The change is about where the event comes from, not about reflection.
The container keeps its
reflective fallback, which its default `InvalidReferenceMode` selects,
so an event with no binding
is still built by a constructor that takes no argument. An application
that dispatches by id today
therefore keeps working without a binding.

The dispatcher does not override that mode. The fallback is the
container's decision to make, and
one component must not hold a private opinion about how the container
resolves a missing binding.
Removing that fallback is step 3 of the migration path in
`CONTAINER_BINDINGS.md`. That step belongs
to the Container component, and it needs its ow... (continued)

1881 of 1881 branches covered (100.0%)

Branch coverage included in aggregate %.

11 of 11 new or added lines in 2 files covered. (100.0%)

6867 of 6867 relevant lines covered (100.0%)

4.32 hits per line