Usually it doesn’t matter what abstractions you choose when you try to factor them to support hypothetical future work, because chances are you incorrectly anticipate future needs.
In other words, generic code that only supports one use case will almost certainly have to be deconstructed to allow a good generic implementation for 2 use cases, so it is better to just write simple code and factor code out when you can see the real commonalities.
Good abstractions are important for the code to be readable. An AbstractEventHandlerManager is probably not a good abstraction.
The original commenter said that their code was “generic with lot of interfaces and polymorphism” - it sounds like they chose abstractions which hindered maintainability and readability.
Usually it doesn’t matter what abstractions you choose when you try to factor them to support hypothetical future work, because chances are you incorrectly anticipate future needs.
In other words, generic code that only supports one use case will almost certainly have to be deconstructed to allow a good generic implementation for 2 use cases, so it is better to just write simple code and factor code out when you can see the real commonalities.
In other, other words, KISS, YAGNI
Good abstractions are important for the code to be readable. An AbstractEventHandlerManager is probably not a good abstraction.
The original commenter said that their code was “generic with lot of interfaces and polymorphism” - it sounds like they chose abstractions which hindered maintainability and readability.