topleft
topright

OReilly PureMVC Book

PureMVC Book

PureMVC TV

PureMVC TV

PureMVC on Twitter

PureMVC on Twitter

PureMVC on Google

PureMVC Blog-o-Sphere

PureMVC on Linked-In

PureMVC on LinkedIn

PureMVC on Delicious

PureMVC on Delicious

Supporters of PureMVC

Simplicty and Balance
Thursday, 23 November 2006
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:
  1. Accept input from a user or another computer
  2. Process that input
  3. Store information
  4. Retrieve information
  5. 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> 


1 Comments:

Chris Luebcke said...

Man, what the bleep are you doing blogging about MVCs on Thanksgiving? :)

Seriously, looks like fun... kinda. Since MVC, as you correctly point out, is really a meta-pattern made up of a not-universally-agreed-upon set of more concrete patterns, you start getting down to the question of what /can't/ you throw away without it not being an MVC any more.

Believe me, I understand the motivation--I'm working with Cairngorm right now, and while I find it well-structured and road-tested, lightweight it is not.

But if I can play devil's advocate here for a second, let me pose a couple of challenges, not because I'm trying to be an ass but because I'm interested in your answers:

1. Is smaller really better? Since "smaller" probably means fewer actors in the framework, are fewer actors better? Again, where's the line between a lightweight MVC framework and a couple of useful classes/objects/functions?

2. What's the motivating factor behind the goal of technology indepenance (e.g. am I running in the Flash player, Mozilla's engine, etc)? I mean, of course I understand it in prinicple, but in practice might you find yourself sacrificing performance or effeciency on the altar of platform independence? Not that /that's/ ever happened before...

Anyway, I'll keep an eye out for you, and drop me a line/let me know what you're up to.

Cheers,
Chris Luebcke

Delicious
Technorati
Reddit
Furl it!
NewsVine
YahooMyWeb
Stumble
blogmarks
Digg
co.mments
connotea
 
Copyright © 2006-2008 Futurescale, Inc.