views:

57

answers:

3

I'm brainstorming some ideas around a pattern to use for the following scenario.

I have some 3rd party controls that I want to add common functionality to. Functionality is added by handling several of the the events and doing certain things when the events fire along with adding some private variables to hold some state info between events. I want to reuse the code and functionality so this is what I'd typically do.

Create a class for this functionality and pass in the instance of the control that I want to add the functionality to in the constructor.

Then I can add event handlers to the control in the instance of the class.

Can anyone think of alternative patterns to use in order to create this kind of reusable functionality.

+1  A: 

You may want to take a look at the:

  1. Facade Pattern
  2. Decorator pattern
  3. Observer pattern

The facade pattern will allow for you to encapsulate the behavior of the control under the current class. The decorator pattern will allow for you to be able to create stackable controls. The observer pattern will allow for you to manage events.

monksy
The Facade pattern will not encapsulate functionality within a control nicely as the facade pattern should not hold any state between method calls for the control (as per my requirement as stated).Given my description, using the observer pattern would not make sense in this scenario at all.The decorator, ok maybe this one might be suitable ;).... If I am wrong, please do tell me, as I would like a better understanding of how you would suggest implementing this with these patterns.
Dan
Actually, I think Steven is pretty right on here.You use the facade to create the unified interface for the UI controls (think : UserControl). The concept of decorator is similar to using the 3rd party via composition and adding specific functionality. Observer would be used to get the top level control to respond when an event occurs on the 3rd party control.
Scott P
I understand where Observer fits into it now. Though, technically my solution is observer and the Forms Event model in .NET alone could be considered an Observer pattern. Impelementing another Observer pattern into the mis doesn't make sense as my solution is already pretty simple and is using an Observer model already.
Dan
A: 

I feel that the Observer pattern should be helpful. This is how you can use it :

UtilityClass which accepts a control (as you have mentioned): make it observer

Register various Utility classes (and hence controls) to various Events it is interested in : Observable

Now when a particular event occurs it updates various observers where you can delegate the basic eventHandling to the control it is wrapping and also have a place to do custom handling based on the control and event.

Nrj
A: 

The most applicable "Design Pattern" is Observer. The reusable functionality you want to develop can be implemented as simple observers of Control, which subscribe to some subset of Control events. Fortunately, Windows Forms Controls implement many events, making it possible to add functionality from outside the class almost as easily as from within, by the usual sub-classing.

For example, you could add drag and drop support by implementing an observer that subscribed to DragOver and DragDrop (and possibly DragLeave) and performed the appropriate actions based on the DragDropEvent data.

This is an excellent technique to consider, as it allows you to develop such functionality once and add it to many Controls.

bbudge
When you get down to the meat and bones of what I'm already doing, it's all observer behind the scenes. There would be no point in further expanding it out and creating Observer interfaces and follow a strict pattern guideline. Basically I am creating a class where I pass in the control in the constructor and then I delegate events to handle the control events. The event model in .NET is considered an Observer pattern already.
Dan
I agree that this is very straightforward to implement with the existing Control API. I just wanted to state that your approach is a good one.
bbudge
Thanks for your description of the Observer pattern.
Dan