|
We should have a look at some existing code that we would like to improve with this approach, and consider what it looks like with the Reactor approach, versus potential alternatives.
The underlying problems that I saw were:
- There is increasing drift between the sync and async variants of methods. It should be possible to compare these side by side, and see the same logic, in the same visual order, without redundant invocations of callbacks.
- Furthermore, some parts of the logic are entirely extracted into separate methods (for example, a lengthy async method is broken up into smaller methods in a different way than the sync method is).
- There is general redundancy in the code.
Some of this can be cleaned up with relatively small helper methods, or a helper class, without the need to introduce a dependency, and the associated complexity. It might also be possible to take this approach sooner and more incrementally than a large-scale conversion into Reactor.
Are there other reasons to introduce Reactor, apart from code clarity? For example, I am unsure what the "Reactor context" comment above entails. Perhaps there are reasons related to closer integration with our async code, or something else?
|