Hi @Voss1917,
I would always go for one module for each aircraft type.
As a software developer I am used to follow the “seperation of concerns” principle to make my live a bit easier. Seperation ensures that changes made in handling one aircraft type’s event handling will not change the behaviour of other aircraft types, therefore limiting the need of testing to the one aircraft type you worked upon.
Mixing event handling of all aircraft type would mean to test every aircraft type after changing code and, even more restrictive, after each build.
The examples above aim at souce code changes made by yourself. Even worse, changes made by the airplane types’ suppliers would mean to test whether your code still works. And even in this scenario a limitation to one aircraft type will be an advantage, limiting the testing effort to a minimum that has been done.
Last but not least, when both scenarios come together, i.e. you changed your code for aircraft 1 and while doing so, aircraft 2 gets an update from its supplier, and you find your code for aircraft 2 is not working any more, you will not know whether it is a side effect of your own changes aiming at aircraft 1 or an incompatibility of the changes the update of aircraft 2 implies.
Another hint that seperation will be a good thing is when your code base increases. Then you will probably search for ways to split your code into (at least) one section for each aircraft - a thing that seperation into several modules will provide out of the box.