Design pattern for serial terminal application

I am working as a single developer on an in house serial terminal application. My goal is to write a framework that is flexible enough that I can use it to create three separate applications:

• Serial terminal application (much like HyperTerminal)
• Data analysis application (will sort and display serial data according to certain criteria)
• Decoding application (will process serial data and display related information from a database)

At some point in the future, I would like to merge these three applica开发者_Python百科tions into one. However, this is far from a priority.

I have separated the framework into three separate pieces - the GUI (View interfaces), the backend (Controller interfaces), and the settings handler (ISettingsHandler interface). However, I have already run into some circular dependency problems (ISettingsView had to be moved to the same namespace as ISettingsHandler), indicating more trouble down the road.

My requirements for each application are as follows:

• Serial terminal - GUI must be able to transmit data to and from the serial port, display and modify settings, and send files
• Serial analysis application - GUI must be able to retrieve incoming serial data and display and modify settings
• Decoding application - GUI must be able to retrieve incoming serial data

Have I made this more complex than it should be? I know I could accomplish the same thing with fewer interfaces, but I'm concerned about the flexibility of this framework for future use. Is there a design pattern that fits this scenario?

EDIT: To clarify, each of the three 'pieces' of the framework are in different namespaces.

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

---

One of the design principles is "Hollywood principle" which states "You don't call, we will call you" (from Head first design patterns)

Circular dependency is a common problem. To avoid it follow this principle.

Don't refer higher layer interfaces/classes in the lower layer. Higher layer classes should make use of lower layer interfaces/classes.

For example, ISettingsHandler should have a reference to IController and not the other way. Even when you are implementing concrete classes try to follow the principle.

Your code will be more maintainable.

---

If you are running into circular dependencies, you need to extract the shared resources into a different project (Ex: put all Interfaces into MyProject.Contracts project). However, if you follow proper layering, you shouldn't have these issues.

---

Here you can use Interface Dependency Injection which is based opon hollywood principale