Aloha,
In the past, if I found myself repeating events, I would create a behavior to encapsulate that functionality. For example, common math functions such as vector.dot, etc...
I have picked up alot of particular habits associated with c# in monogame and unity, and for lack of knowing any better, I find myself implementing them here. In the past 8 years, I have primarily used construct as a prototyping tool, and didn't concern myself with the architecture concerns.
The question I have, is it better to break behaviors down into the smallest possible functional bits in accordance with SOLID, or is it better to group common behaviors into a singular behavior. If Scirra built behaviors are any example, then they choose to make behaviors have more than a Single responsibility (platformer behavior handles input/commands -> objectHandler -> stateManagement -> collision response), but this is possible they chose that route for beginner ease, not because its the best way to manage projects.
For example, for an input/command behavior, I could create a behavior that tracks commands (up,down,left,right,jump) and maintains a record of them several frames back. If I had an object that only needed left and right, using such a behavior would break SOLID principles (bloating an object with features it won't use). As would the platformer object for an object that never needs to jump.
At the moment, the only way I can figure how to avoid the above is to create a simple behavior for tracking a singular command, and then simply adding it to an object as many times as you have distinct commands. Adding a further command is as easy as adding the behavior again, rather than editing the behavior itself to add something most objects wouldn't need.
But then, lets say I have a platformer handler, I don't see a way to force the object to have the prerequisite behaviors installed, and would have no way of teing them neatly together in a way that wouldn't result in even more work. I could also implement the ability to dynamically add commands to a single behavior via a dictionary, but then I'm recreating functionality that already exists in other behaviors.
The issue here is that my mind in firmly in a unity paradigm and I am treating behaviors as I would object scripts in unity. I never repeat myself, but I'm finding it hard in construct. Am I thinking about things wrongly?
The goal is to have neat, reusable code, that I can efficiently maintain, scale, add to, but the net result should be less work, not more.