Build something so simple a fool can use it, and only a fool will use it.' - Folk saying
'Make it as simple as possible, but no simpler.' - Einstien
'Balance, Danial-san.' - Mr Miyagi
I read a story about a man who used a massively parallel computer system to generate optimal code. The goal was to 'evolve' an algorithm that could not only sort the data set, but do it faster than any human-written code for that processor.
He populated each processor's data area with an exact copy of a randomized set of numbers, and its program space with uniquely random gibberish. Of course, most of the 'programs' were completely useless. But some of them actually push the data toward a more orderly state. The only way to tell is to run them all and then analyse the data, over and over.
Those 'programs' that actually had some positive effect were held over to the next cycle. Those that didn't had their programs randomized again. And to simulate cross-polination, sometimes snippits of the 'successful' ones got merged into the new gibberish (or other successful contenders) at random places.
So he cooked that gumbo for a while, and eventually evolved a program that whipped the pants off the best human attempt! It was an unbelievably tiny program but it could sort like nobody's business.
The only problem was, no human could understand it. It was as if aliens had written it. There was no sense to be made of its inherent strategy.
It was very small, but utterly incomprehensible.
The point here, is that to some, a program to perform any given task might be considered to be at its simplest when expressed in the fewest lines of code. But the exact meaning of the term simplest can sometimes be unclear.
Must the software be scalable to perform other tasks in the future? Must it also be understandable by others who will maintain it? When these questions aren't asked before the code is written, spaghetti code and high cost of ownership is the inevitable result.
This is where design patterns save the day, because others have already thought about most of the problems we face on every application. Though applications are myriad, the number of basic functions performed by a computer are extremely limited.
Essentially, a computer does only 5 things:
- Accept input from a user or another computer
- Process that input
- Store information
- Retrieve information
- Output information to a user or another computer
That's it. Nothing else.
So why is writing simple software so hard?
Because there are so many details. And every detail requires a decision at implementation time. At each turn, abstraction can lead to reusability and maintainability, but also requires more time, effort and planning than does a 'brute force', hard-coded solution. And the errors made during all the decisions accumulate to make creaky, fragile software.
Once a helpful abstraction is conceived, a software framework based upon it can be a terrific way to ensure that your implementation will not only work, but that your developers will spend more time focused on the business problem and less on working out how to wire everything together.
The MVC (Model-View-Controller
) pattern describes a simple division of the application's responsibilities into three areas.
- Model - Representation of the business domain
- View - User interface
- Controller - Mediator between the Model and View
Making this basic separation between areas of code allows you to easily change around the interface without changing the data representation or vise-versa.
Generally, the term MVC is a sort of 'meta-pattern', which is implemented as a combination of other more specific design patterns. These patterns define a group of 'actors' (classes or interfaces), each with a specific role and set of responsibilites. The pattern also defines the collaboration or messaging between the actors.
There are many real-world implementations of the MVC meta-pattern
for various languages and platforms. The patterns chosen and the actual implementation of the classes and interfaces involved make an interesting study in the search for Simplicity and Balance.
There is much confusion about what exactly MVC is, was, or should be.
And the question remains; How simple can a Model-View-Controller framework be and still be useful? -=Cliff>