Unit Testing with the Mediator Pattern - All Private to Public

Question

I am using the mediator pattern to facilitate unit testing of GUI objects.

psudo code Example:

Class MyGuiClass
{
  //...  Declare and initialize mediator to be a MyMediator
  private void On_SomeButtonPressed()
  {
     mediator.SomeButtonWasPressed();
  }
}

Class MyMeditator
{
  public void On_SomeButtonPressed()
  {
     //.. Do something now that the button was pressed
  }

}

This is nice because I can now unit test what happens when SomeButton is pressed without having to create a Window.

My concern is that I have taken a method that was private and made it public for any one who makes a Mediator to call. Past times I have done this it did not bother me because I did not have many methods that I had to make public.

I am currently refactoring a very large class to use this pattern and I am wondering if there is someway I can control the visibility of who can make a MyMediator or which classes some of the methods are public for. (This may not be possible or even needed, but I thought I would ask.)

(I am using C# 3.0 with .NET 3.5 SP1)

Answer 1

I think it doesn't matter.. Who has an instance of the mediator, other than the gui? If someone does, is it going to call the method? If it does, does it matter? Will it be hard to notice, diagnose and fix the bug?

I think you can achieve what you are looking for with events though:

e.g.

/* in the gui class (view) */
public event EventHandler OnButtonClicked;

/* in the mediator */
public MyMediator(MyView view) 
{
    view.OnButtonClicked += HandleButtonClicked;
}

private void HandleButtonClicked(object sender, EventArgs e)
{

}

Answer 2

Not sure about c#, but in java you can declare something as package-level access (in java by omitting the access specifier). What I do is create a separate test hierarchy that parallels my package structure, so to test class com.a.b.c.MyClass, I'll have a test class com.a.b.c.MyClassTest, which can then legally access the package-access methods in MyClass.

I don't so much like the idea of making everything public not only because of access issues, but because it clutters up the interface - I'd rather the public interface of the class express what it does, not how it does it, which is often where I end up if I expose methods I'd prefer to be private.