Pretend1 there is a place to type in a name:
Name: __________________
When the text box changes, the value is absorbed into the controller, who stores it in data model. Business rules require that a name be entered: if there is no text entered the TextBox should be colored something in the view to indicate baddness; otherwise it can be whatever color the view likes.
The TextBox contains a String, the controller handles a String, and the model stores a String.
Now lets say i want to improve the view.
There is a new kind of text box2 that can be fed not only string-based keyboard input, but also an image. The view (currently) knows how to determine if the image is in the proper format to perform the processing required to extract text out of it. If there is text, then that text can be fed to the controller, who feeds it to the data model.
But if the image is invalid, e.g.3
wrong file format
invalid dimensions
invalid bit depth
unhandled or unknown encoding format
missing or incorrectly located registration marks
contents not recognizable
the view can show something to the user that the image is bad.
But the telling the user that something is bad is supposed to be the job of the controller.
i'm, of course, not going to re-write the controller to handle Image based text-input (e.g. image based names).
a. the code is binary locked inside a GUI widget4
b. there other views besides this one, i'm not going to impose a particular view onto the controller
c. i just don't wanna. If i have to change things outside of this UI improvement, then i'll just leave the UI unimproved5
So what's the thinking on having different views for the same Model and Controller?
Nitpicker's Corner
1 contrived hypothetical example
2 e.g. bar code, g-mask, ocr
3 contrived hypothetical reasons
4 or hardware of a USB bar-code scanner
5 forcing the user to continue to use a DateTimePicker rather than a TextBox