The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How do you seperate code and GUI?

Seriously.  This seems like it's more trouble then it's worth.  No matter what GUI you attach, there are always levels of cohesion and overlap between the two code layers.  My specific focus is Win32 GUI programming.
sedwo Send private email
Friday, October 22, 2004
Christopher Wells Send private email
Friday, October 22, 2004
Have you considered the User Interface Process Application Block, from Microsoft Patterns and Practices ?

Even if the actual implementation is not to your liking, the concept of splitting the UI presentation from the UI control is a good one.
Friday, October 22, 2004
Check MVC pattern:

Then think in term of interfaces and components. Think IoC (Inversion of Control:

Correctly implementing MVC is non-trivial - you probably need at least 3 iterations to get the code right, more if it is a first time for you.

Is it worth it? IMO yes, especially if you're building a large system. But that's just me.
Friday, October 22, 2004
Yes, it normally takes an iteration or two (refactoring is the word for this), but it offers some huge power as it means your interface can be in asp, mfc, php, or whatever you happen to choose.
KC Send private email
Friday, October 22, 2004
Also, it's much easier to test.

That said, I'm having a tough time making my own programs' UI independent from the rest of the program.

Of course, it's the very dynamic & rich UI (which we want) that makes it hard to seperate the UI from the rest of the program.
Mr. Analogy {Shrinkwrap ISV owner} Send private email
Monday, October 25, 2004
Basically you put an interface on the class that is your form, then have it register itself with a UI Object that does all the work.

The trick is abstracting the Form's UI so can divide up the work between the different objects.

Let take a simple paint program. It has three UI elements. A menu strip across the top, a toolbar along the side, and a drawing area in the middle of the screen.

You will need to provide a set of members to manipulate the menus. A set of members to manipulate the toolbar. A canvas object representing the drawing area.

The UI Object will need members that represent the event such menu click, toolbar click, mouse move, mouse down, etc.

So you would have something like this

Public Interface IPaintForm
  ReadOnly Property Canvas as ICanvas
  Sub AddMenu(Parent as String, Text as String, Key as String)
  Sub AddToolbar(Image as IImage, Text as String, Key as String)
End Interface

Public Interface IPaintUI
  Sub ToolBar_Click(Key as String)
  Sub Menu_Click(Key as String)
  Sub Paint_MouseDown(X as Integer, Y as Integer)
  Sub Paint_MouseMove(X as Integer, Y as Integer)
  Sub Paint_MouseUp(X as Integer, Y as Integer)
  Sub Init()
End Interface

Now what this does for you is several things

1) You can subsitute a test object implementing IPaintForm for automated testing. This is the #1 reason for going through all this.
2) You can freely change the Form as long as the new form continues to implement IPaintForm
3) If your framework changes the areas you need to change are isolated. In this example ICanvas, IImage, and of course IPaintForm.
4) The Interface definitions make it very clear what being communicated.
5) The class members implementing IPaintUI can execute command objects implementing the GoF Command Pattern. This makes it real easy to do Undo/Redo.

For more information see
Robert Conley Send private email
Monday, October 25, 2004
The key to creating this separation is building a unit test against the Model which tests all of the business/application functionality - even little things like sorting of result sets.  This way the Model object you have just created is fully tested and can be used from any front end. 

If you follow  Test Driven Design principles your end product will be a test and a working group of support objects.  Then just develop whatever UI to fit on the Model.

Refactoring from an existing tangled UI is a different headache but can be done the same way.
Brettt Send private email
Monday, October 25, 2004
In particular see:

If you are using .NET, don't rule out databinding. (You don't have to bind to datasets.)  Martin Fowler says it's not mature enough in .NET 1.x.  I think it can still be useful in .NET 1.x, but its certainly improved in Whidbey.
John Rusk Send private email
Monday, October 25, 2004
Sepparating the M V & C is not easy. In most cases, presentation requirements are mixed with business and transactioning requirements and a clear sepparation is not apparently possible.

Re-think the requirements in terms of services.
Tuesday, October 26, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz