Extract "Core" logic into separate project(s) #27
Description
Suggested Change
Certain widely used classes that define and implement concepts that are crucial to the functioning of (large parts of) STROOP should be extracted into separate C# projects in the same solution, and their specifications should be sharpened.
Specifically, what is described by NamedVariableCollection and how it is used should be separated from specific use cases and "Tab" implementations.
Rationale
Currently, many core concepts are uncleanly intertwined with specific use-cases.
Isolating concepts that belong together within a dedicated C# project facilitates cleaner program architecture by providing a clearer dependency graph, as well as the ability to hide certain implementations using the internal modifier.
Cleaner program architecture, in turn, facilitates modular design, which is an eventual architectural goal, with "tabs" roughly describing what would become a "module" then.
Considerations
Many features of STROOP are currently implemented with hacky workarounds and by conflating concepts that should be clearly separated, such as "Variable views" being either bound to XML files or being dynamically generated, or sometimes even a combination of the two. Separating already conflated concepts may require breaking some features, or re-implementing them in a wildly different way (potentially requiring a redesign).
However, said such redesigns should always end up more powerful and convenient than what is in place now, being powered by more well defined concepts that can more cleanly interact with each other.
Affected Features and Concepts
- All classes and code directly involved with interfacing with the emulator
- All code that works with "Variable views", i.e. anything in
NamedVariableCollection - The XML files defining the way variables should be displayed, as well as how their underlying memory is defined (these are apparently already two conflated concepts that should be separated from each other eventually - not in this issue though)