A GUI design issue

[Guest]

This must be a common GUI design issue - whether to treat the GUI object
which represents a thing as if it were the thing itself.

I'll put it in the form which I've come across recently...

I have a GUI which is a controller for an instrument, and I have a
UserControl which represents the instrument.

Imagine that the UserControl has a text box for the instrument frequency,
and a button to turn it off and on.

A couple of classes, apart from the GUI, access the instrument.

So the outline is... (making some simplifications)

class Instrument: UserControl
{
// public stuff, which is synchronised with the GUI
public double Frequency;
public bool isStarted;
public void Start();

// private implementation of the GUI
private TextBox frequencyControl();
... other GUI elements...
}

Instrument instrument;

class InputController
{
if (!instrument.isStarted)
{
instrument.Start();
instrument.Frequency = GetFrequencyFromExternalSource();
}
}

class OtherInstument
{
double myFrequency = (instrument.Frequency * 1.5);
}
}

The good thing about this is that it is simple. The problem is that every
class which depends on the Instrument, also depends on Windows.Forms. In
addition, because Instrument is actually quite large, and complex, the
complexity of the GUI is combined with the complexity of the the application
doman.

Should I break Instrument into two classes? ...

// The real instrument
Instrument
{
double Frequency;
bool isStarted;
void Start()
}

// The GUI
InstrumentControl: UserControl {...}

The GUI InstrumentControl, the InputController, and the OtherInstrument, all
access the more primitive Instument class.

My gut feeling is that I should do the separation, but in the real world
case I am dealing with, the Instrument actually has many properties and
methods, so making the two classes will see a lot of duplicated code, all for
the sake of an aesthetic improvement, with negligible real advantage. On the
other hand, I like my designs to represent "best practice".

TIA,

Javaman

 

[shiv_koirala]

I understand your concern that GUI elements are getting up tied with
classes. But if really the class has to aggregate the GUI elements
thats fine. I mean if class is depenedent on UI element you have to use
it. If you are predicting forthe change from windows forms to web form
or viceversa you have to keep them seperate. In tier technology when we
say UI element should be independent of UI we mean that if we want to
remove windows forms and plug in web forms its should be done with
minimal changes. If you think you have to cater to windows as well as
webforms UI elements the seperattion is worth doing it.... or else will
just increase the complexity of project
-------
Regards ,
C#, VB.NET , SQL SERVER , UML , DESIGN Patterns Interview question book
http://www.geocities.com/dotnetinterviews/
My Interview Blog
http://spaces.msn.com/members/dotnetinterviews/

 

[Robbe Morris [C# MVP]]

Will you be deploying your control via the .NET Compact Framework
or even an ASP.NET environment? If your control works well
in Windows, you can bet they'll ask for flavors in other environments
in the near future.

If it were me, I'd keep as much of it that isn't dependent on
one environment or the other in separate classes. I wouldn't
mind repetitive code closer to the actual UI code but I'd
do everything I could to shove as much of it as possible
into the shared classes.

 

[Guest]

Thankyou guys, both replies are very helpful. I had not thought of the issue
of web deployment, and I can say that in this case the control is part of a
much larger, and complex GUI which will not be deployed as a web form,
however there is some chance that the GUI could be required to *remotely*
control the instrument, in which case the Instrument object would be on a
separate platform to the GUI, or perhaps multiple GUI's. In the light of your
overall comments, I think that consideration is enough to justify making the
separate class.

Thankyou both for taking the time to share your insights.

Shiv, I liked your summary...

If you think you have to cater to windows as well as
webforms UI elements the seperattion is worth doing it.... or else will
just increase the complexity of project

and Robbie, your opinion...

I'd do everything I could to shove as much of it as possible into the shared
classes.

Although you are offering different recommendations (we are talking here of
the non-web case), your opinions and experience sum up the issue.

Javaman

 

[kevin cline]

This must be a common GUI design issue - whether to treat the GUI object
which represents a thing as if it were the thing itself.

I'll put it in the form which I've come across recently...

I have a GUI which is a controller for an instrument, and I have a
UserControl which represents the instrument.

Imagine that the UserControl has a text box for the instrument frequency,
and a button to turn it off and on.

A couple of classes, apart from the GUI, access the instrument.

So the outline is... (making some simplifications)

class Instrument: UserControl
{
// public stuff, which is synchronised with the GUI
public double Frequency;
public bool isStarted;
public void Start();

// private implementation of the GUI
private TextBox frequencyControl();
... other GUI elements...
}

Instrument instrument;

class InputController
{
if (!instrument.isStarted)
{
instrument.Start();
instrument.Frequency = GetFrequencyFromExternalSource();
}
}

class OtherInstument
{
double myFrequency = (instrument.Frequency * 1.5);
}
}

The good thing about this is that it is simple.

Not for long.

The problem is that every
class which depends on the Instrument, also depends on Windows.Forms. In
addition, because Instrument is actually quite large, and complex, the
complexity of the GUI is combined with the complexity of the the application
doman.

Should I break Instrument into two classes? ...

Definitely. If you don't it will quickly become extremely difficult to
maintain. I like to keep the GUI layer as thin as possible, so that
control event handlers merely forward the information to a model class,
and control appearance is updated only in response to the model
changing:

class DomainModel
{
public int SomeProperty { get { ... } set { ...; OnChange(); } }
public bool Frobbable { get { ... } }
public void Frob() { ...; OnChange(); }
public event EventHandler Changed;

private void OnChange()
{ if (Changed != null) Changed(this, EventArgs.Empty); }
...
}

class DomainModelGui
{
public DomainModelGui(DomainModel model)
{
...
this.model = model;
model.Changed += model_Changed;
}

public void model_Changed(object sender, EventArgs unused)
{
somePropertyTextBox.Text = model.SomeProperty.ToString();
frobButton.Enabled = model.Frobbable;
...
}

private void frobButton_Click
{
model.Frob();
}
...
}

Notice that none of the control event handlers have to worry about
changing the state of other controls. Every time the model changes,
the appearance of every control is refreshed.

// The real instrument
Instrument
{
double Frequency;
bool isStarted;
void Start()
}

// The GUI
InstrumentControl: UserControl {...}

The GUI InstrumentControl, the InputController, and the OtherInstrument, all
access the more primitive Instument class.

My gut feeling is that I should do the separation, but in the real world
case I am dealing with, the Instrument actually has many properties and
methods, so making the two classes will see a lot of duplicated code

There should not be any duplicated code. One class implements the
domain logic, and the other maps the domain object to GUI controls.
Additionally, by separating the domain logic from the GUI, you
automated testing of the domain logic.

 

[Kevin Spencer]

A GUI is just that: an interface. An interface is something that links one
thing with another thing. In this case, a user with a process. The process
may be exposed through any number of interfaces, including other user
interfaces, and other processes, via an API. Perhaps you're thinking, no,
that isn't going to happen in this case. Well, life is long, and many times
I've been surprised at how something I've written needs to be re-purposed.

Therefore, while the user interface should know how to "talk to" the
process, it should never participate in the process.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[Guest]

And thankyou to the two Kevins. I'm really glad that I asked this question,
as the responses have been first rate, and really helped me get to grips with
this problem.