So to be able to change the user interface without much trouble is a must. But with a lot of applications I saw, this is not possible.What is the problem? The user interface contains to much logic.
This is a problem that many people had and there are some easy ways to solve this...
When a couple of people found the same problem and a solution for it, we can call of a pattern. A pattern is just a description of the solution and not the solution itself, so most of the time you have to modify the pattern a little bit to make it work efficiently in your own situation.
In MVC we have the Model which is just the data that is requested by the user. The View is the actual form that shows the data from the Model and it will send actions from the user to the Controller. The Controller is responsible for giving the View the right data and update the Model. When the Model is updated it will send a notification to the View and the View will update itself.
Now this is a basic and fast description of MVC and there are a lot more (and better) descriptions on the internet and in books ;)
Changing the user interface
Using this patterns makes it really easy to change the user interface, we can easily make a new view and add it it to the Presenter. How these are coupled is basically a matter of taste. I tend to go for Dependency Injection, but it is also possible to give the Presenter a little more knowledge and let it create the view manually.
Although I am not sure about it because I never tried it, I think the MVC pattern family make it easy to change from a desktop application to a web application. There will be some changes in the infrastructure, but in the presenters and the models there shouldn't be much differences.
Testing the presenters
Testing the user interface is difficult, and testing logic in the user interface even more difficult. Using the MVC pattern makes it pretty easy to test at least the most of the logic since the logic is inside the Presenter. We can create a simple version of the view to test whether information is send to it and we can use it to see if the events are working.
So the only not tested parts of the system are the actual views, these should be tested by humans because automated tests will be to complicated (although there are tools who can do this...)
When you have a problem and don't know how to solve it, it is great to be able to find a pattern that describes a possible solution. The problem is that you should have seen the pattern before you know that you can use it. That was basically the purpose of this post. I introduced you to the problem of a fat UI and I mentioned a pattern that could solve the problem. But there are a lot more patterns you probably wan to know about. Therefore I want to redirect you to a few sites: