Organizing GUI code

Question

My question has two parts:

• Does anyone have any tips or references to some documentation on the web about how to write GUI code that is easy to read, write, and maintain?

  Example.

  I find that the more extensive my GUI forms become, I end up with a long list of fairly short event handler methods. If I try to add any private helper methods, they just get lost in the shuffle, and I constantly have to scroll around the page to follow a single line of thought.

---

• How can I easily manage settings across the application?

  Example.

  If the user selects a new item in a drop-down list, I might need to enable some components on the GUI, update an app config file, and store the new value in a local variable for later. I usually opt to not create event handlers for all the settings (see above), and end up with methods like "LoadGUISettings" and "SaveGUISettings", but then I end up calling these methods all over my code, and it runs through a lot of code just to update very few, if any, actual changes.

Thanks!

Answer 1

If you're using WPF, you might want to read the Composite Application Guideance for WPF.

It discusses many of these topics (as well as many others). The main goal of that guideance is to make large scale applications in a flexible, maintainable manner.

Answer 2

You should definitely look at Jeremy Miller's guide to rich client design. It is incomplete, but I believe he is writing a book on the subject.

Another blog you should check out is Rich Newman's. He is writing about Composite Application Block which is a MS best practice guide on how to structure rich clients.

You can also read this book which is only a very light read but gives you some good ideas.

Answer 3

Some guidelines for the first question, from an OO perspective:

• Break up large classes into smaller ones. Does that panel have a bunch of fairly modular subpanels? Make a smaller class for each subpanel, then have another, higher-level class put them all together.
• Reduce duplication. Do you have two trees that share functionality? Make a superclass! Are all of your event handlers doing something similar? Create a method that they all call!

---

Second question. I see two ways of doing this:

• Listeners. If many components should respond to a change that occured in one component, have that component fire an event.
• Global variables. If many components are reading and writing the same data, make it global (however you do that in your chosen language). For extra usefulness, combine the two approaches and let components listen for changes in the global data object.