Mediator pattern

It has been a long time since my last “pattern focus” but I think I’m ready to pick it up again. This time I want to talk about the mediator pattern, the UN diplomat of patterns.

I have a funny history with this pattern. When I first used it I patted myself on my back really proud of the code design. By then I did not know that the implementation was a known pattern, I had just made sure that my implementation honored the Single Responsibility Principle (separation of concerns). the Liskov Substitution Principle and basic OO reuse. A living proof that the principles behind software design drives code into the same basic patterns of implementation in many code bases around the world.

The project where this code emerged was a windows forms project and the “problem” was to reuse validation with multiple controls and across multiple forms. In my first attempt I tried to reuse the “Validating” event handler. That did not scale well enough across forms so I decided that I needed something else.

My second attempt was to subclass the textbox, but that meant either to create extra events that someone had to subscribe to or make the new textbox depend on any other error informing method like requiring a ErrorProvider to be passed to the constructor . Adding that kind of dependencies was not an option, additionally this approach would also disqualify any third party textboxes already extending the textbox class (a reality in this project) from reusing the validation logic.

For my third attempt I decided to create a class that would “mediate” between the textbox and the ErrorProvider on the form. Using mediation I could defer from using inheritance and did not have to add extra dependencies to my textboxes, thus enforcing SRP and a couple of other three letter abbreviations. It also enabled reuse of the validation for any kind of textbox, not just a certain type.

Enter the star of this post: The TextBoxNotEmptyValidator class.

The design was simple, inject the textbox and the error provider from the outside and let the validator class handle the communication between them (And yes MVC/MVP might have solved the same problem, but that is past the point of this discussion).

The class looked like this:

public class TextBoxNotEmptyValidator { private ErrorProvider errorProvider; private TextBox textBox; public TextBoxNotEmptyValidator(TextBox textBox, ErrorProvider errorProvider) { this.errorProvider = errorProvider; this.textBox = textBox; this.textBox.Validating += TextBoxValidating; } protected void TextBoxValidating(object sender, CancelEventArgs e) { if (string.IsNullOrEmpty(textBox.Text)) Tell("Textbox can't be empty"); else ClearAnyError(); } private void Tell(string message) { errorProvider.SetError(textBox, message); } private void ClearAnyError() { errorProvider.SetError(textBox, string.Empty); } }

A pretty simple implementation; no inheritance needed and fully reusable. The usage was even more simple:

TextBoxNotEmptyValidator validator; . . validator = new TextBoxNotEmptyValidator(textBox1, errorProvider1);

A classic mediator; take two unrelated objects and make them interact with each other using reusable code. This is a standard implementation of the mediator pattern, it could be further enhanced by removing the dependency from concrete classes (TextBox and ErrorProvider) and depend on interfaces instead. For this particular implementation I choose not to, the extra level of indirection would be a pointless exercise since the only scenarios where the validator ever were used just involved textboxes and errorproviders. Later in this project I also combined the mediator with the ”composite pattern” to make the reuse even easier and to minimize DRY violations, I will follow up with a separate post on that.

Lowendahl's Shout

Other pattern examples:

Leave a Reply Cancel reply