However, there is one thing in my post that does go directly against what is in the Best Practices document, and that is creating methods on the concrete Mediators that expose methods of manipulating the view from outside of the Mediator. The reason that I choose to write my implementations this way is that I can more quickly see what happens as a result of a notification if all the actions are invoked by the registered command. Which is what I was trying to convey in the last example, where I can see that the notification that triggered the PlaylistLoadedCommand invoked methods on two Mediators and one Proxy. This approach lets me debug my code easier, as well as lets me reuse methods of a Mediator or Proxy if they are needed to be called from other Commands, as well as keeps the mediator less coupled to the notifications that trigger certain Mediator actions. I've found this very useful in being able to move a Mediator to another application with very little effort in integrating its functionality, since I just have to register the mediator to a Facade and retrieve it in a command where I need to invoke one of its methods.

In the end, this is one of those things that I think is completely a matter of preference, this just happens to be what I prefer. We usually make these types of preference choices on how it effects the way in which we write and debug code, these approaches have helped me. Hopefully they help someone else, but I don't expect everyone to agree.