Design scheme for serial terminal

Question

I work as a single developer on an embedded terminal application. My goal is to write a framework flexible enough so that I can use it to create three separate applications:

• Serial terminal application (like HyperTerminal)
• Data analysis application (sorts and displays sequential data according to specific criteria)
• Decoding application (will process serial data and display relevant information from the database)

At some point in the future, I would like to combine these three applications into one. However, this is far from a priority.

I divided the structure into three separate parts: GUI (View interfaces), backend (controller interfaces) and settings handler (ISettingsHandler interface). However, I have already encountered some issues with circular dependency (ISettingsView had to be moved to the same namespace as ISettingsHandler), which indicates a big problem with the road.

My requirements for each application are as follows:

• Serial terminal - The GUI should be able to transfer data to and from the serial port, display and change settings, and send files
• Sequential Analysis Application - The GUI should be able to receive incoming serial data and display and change settings
• Decoding application - GUI should be able to receive incoming serial data

I made it more complicated than it should be? I know that I could do the same with fewer interfaces, but I am worried about the flexibility of this structure for future use. Is there a design template that fits this scenario?

EDIT: To clarify, each of the three “parts” of the frame is in different namespaces.

I have installed circular dependency, however I'm still not sure if this is the best design pattern for this application. Any recommendations?

Answer 1

One of the design principles is the "Hollywood principle", which says: "You do not call, we will call you" (from the first examples of head design)

Circular dependence is a common problem. To avoid this, follow this principle.

Do not link to higher-level interfaces / classes at the lower level. Higher classes should use lower level interfaces / classes.

For example, ISettingsHandler should have a link to IController, and not vice versa. Even when you implement specific classes, try to follow the principle.

Your code will be more convenient.

Answer 2

If you use circular dependencies, you need to extract the shared resources into another project (for example: put all the interfaces in the MyProject.Contracts project). However, if you follow the correct stratification, you should not have these problems.

Answer 3

Here you can use Injection Dependency Injection based on opon hollywood principale