My team is communicating proposals for the interaction of several processes as a flowchart. I've been drafting a codebase architecture we can use as a starting point. There are two ways intended behaviour can change, each of which poses maintainability issues:
- What each edge does. Edges are in general bidirectional, allowing one node to query another for information. Multiple copies of a given flowchart may be executed, with different behaviours of the node objects.
- How the flowchart looks, due to adding/removing nodes/edges.
My current approach, which addresses the first issue, is to make each node an instance of a daughter of a parent class on which edges execute with a method. So no matter how varied instances of a specific flowchart become, we just need to use instances of suitable daughters.
But the second issue is poorly addressed. When the flowchart changes, I need to reconsider what classes are needed, what methods they need to handle their interactions, what fields/properties are needed and when they're set or modified, and how to prevent cyclic dependencies between classes. (I'm working in Java, which has to mention the types of any arguments passed to constructors, plus we'll likely split across multiple files.)
What's a more maintainable approach? I don't want decisions made now to trip us up when we start filling in the methods of mostly empty classes in the current draft. This is especially likely to happen if it's realized only once such filling in begins that the flowchart needs to change again.