Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a UI control that uses a provider class to implement the actual logic of a complex task. So the control delegates to the provider to do some work. But the provider needs to work with the control too; it needs to fire some events on the control.

I was looking for a good design pattern of how the two could work together, but wasn't sure of any. I didn't want the provider to directly invoke events on the control. I thought about methods on the control that it could call, but I don't know that I quite like that either.

Any ideas, thoughts? What is a good design pattern that the provider can use to fire a notification through the control? Each event may also need to pass custom parameters too.

share|improve this question

closed as too broad by gnat, MichaelT, Robert Harvey, Kilian Foth, Dynamic Nov 23 '13 at 0:03

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

What exactly is wrong with your proposed solution of coupling controls to providers? If you think the coupling is too tight then you could abstract the control event interface and plug in the proper proxies for the controls but this adds extra complexity and indirection and is actually premature optimization which I hear is evil. – davidk01 Jul 15 '11 at 20:48
classic MVC pattern applies here – Steven A. Lowe Jul 15 '11 at 21:28
@davidk01 It's more that I feel the coupling of the provider to the explicit control reference, and making the On<Event> methods internal/friend so that the provider could call it. Making them public didn't feel right. – Brian Mains Jul 16 '11 at 0:34
up vote 2 down vote accepted

I can think of two models:

Using callback functions

If your language supports passing functions as parameters, then you can call the provider's method from UI, passing it a function to be executed at the appropriate point. C# and JavaScript support this method. The code can be something like this:

function successCallback () {
    // This function is written in UI and belongs to UI, but would be executed in provider.

Using events

In this model, you can expose custom events in your provider to the external world. This way, you can provide event handlers for those events in your UI. For example, imagine that a provider tries to validate an order. This provider can expose an event called OrderValidated to the external world, and UI is just something existing in that external world. UI on the other hand can provide a handler for that event called HandleOrderValidated. In fact, UI subscribes to an interesting moment of the internal life-cycle of provider, and when that interesting moment comes to reality, provider informs any subscriber, and each subscriber takes its own action.

share|improve this answer

protected by GlenH7 Nov 20 '13 at 12:42

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.