4

This might be a bit vague, but I am working on a program where several classes that update the UI. I have made a "middle-man" class that basically takes all the UI requests (among other things) and routes them to the UI itself, that way the UI class only interacts with the middle-man.

The problem is that the UI class has ~20 different functions in its interface, and all my middle-man class does is basically take calls from the lower-level classes and then call an essentially identical function in the UI, which makes me wonder if this is somehow defeating the whole purpose. I'm sure this is a problem that comes up a lot. Is there any more elegant way to do this?

Thanks,

PM

user472875
  • 3,115
  • 4
  • 37
  • 68

2 Answers2

2

It's nice to not have to refer to UI stuff in the backend. I assume this is the reason you're wanting to do this.

If that's the case, what you could do is implement some Publish/subscribe pattern (such as the Observer pattern). That way, you don't have to refer specifically to the UI. You can just "publish" from your backend, and subscribe to those events from your UI.

Alternatively, you could inherit your UI from an interface, and specify the methods you need on that. Then, refer only to the interface in your backend.

Smashery
  • 57,848
  • 30
  • 97
  • 128
  • Or even better (ie. more fun), implement one interface in your UI for each backend class (or however it makes sense). Then you could potentially split the UI into separate classes without the backend ever knowing. – Zooba Nov 10 '10 at 02:20
  • Also, I love that you've got a vibraphone as your profile pic. – Zooba Nov 10 '10 at 02:20
  • Why thank you! I love that you recognise it as a vibraphone and not some similar idiophone. Are you a vibrophonist/percussionist/musician yourself? – Smashery Nov 10 '10 at 02:25
  • Hmmm, I think this would eliminate a good chuck of the functions I have. Suppose I have some field that changes in the back end, does C# have a simple way of publishing the changes to the observers automatically? (it'd be cool to have a keyword "published" that would automatically notify any subscribers of the change) – user472875 Nov 10 '10 at 02:32
  • 1
    http://www.akadia.com/services/dotnet_delegates_and_events.html – Kevin Stricker Nov 10 '10 at 02:46
  • OK, so basically create a new event for each change in an observed field and handle it on the UI end. I would still have to raise the event after each change but I guess I'll try to group my UI interface into several groups, like Zooba suggested and try to have one or two events / group. – user472875 Nov 10 '10 at 02:56
2

Unfortunately you don't really state what you are using to build your UI. But the whole problem can quickly disappear with WPF (or Silverlight) and data binding. In a nutshell items in the UI are bound to properties and commands in a backing class. When a property changes the PropertyChanged event is raised and the UI knows to update itself. For more information start searching on MVVM.

At the end of the day, this is actually a form of the observer pattern, but you don't have to do all the wiring yourself.

Kirk
  • 4,431
  • 1
  • 15
  • 8
  • That's exactly what I've been looking for, sadly the UI is already coded so it is a bit too late to go WPF, but definitely something I'll keep in mind for future projects. – user472875 Nov 10 '10 at 03:10