Model View Kata

William Taysom on Tue, 17 Jul 2007

When you find yourself trying to do too many unrelated things in a class, it’s time to split the class in two. For instance, you put the rules and conceptual behavior (the so-called business logic) in one class know as the model. You put visualization and display details in another class known as the view.

Often your model has parts and you want each of the parts to have an associated view. The view for the main model will have sub-views for each of the model’s parts. Thus we end up with a scenario like this:

  • A ParticleSystem contains some Particles.
  • A ParticleSystem is visualized by a DisplayObjectContainer.
  • A Particle has an optional DisplayObject skin.
  • When a particle is in a ParticleSystem, the particle’s skin is in system’s container.

How would you implement this scenario in your favorite language? Keep in mind the consequences of these for statements:

  • If a particle is added to a system, add the particle’s skin to the system’s container.
  • If the skin for a particle changes, add the new skin to the container of the particle’s system.
  • If the container for a particle system changes, move all the skins of the system’s particles to the new container.
  • Since skin has no more than one parent, a particle with a skin can only be in one particle system.

Also think about potentially desirable properties that do not necessarily follow:

  • If particle is removed from a system, remove the skin from its parent container.
  • If skin is removed from a particle, remove the skin from its parent container.
  • Two particles cannot have the same skin.
  • A particle can only be in one system.

What do you think of your implementation? Is it the sort of thing your language, libraries, and environment support nicely or is it the sort of thing that’s buggy and hard to get right? If its hard, what patterns, protocols, or tests do you use to make it easier?

Too Many Messaging Apps

J Aaron Farr on Fri, 11 May 2007

Any more I tend to have Adium, Colloquy, and Skype open at all times. I’d rather have a single application that handled IM, chat and voice so that I don’t have to deal with multiple contact lists, status indicators, and cluttering windows.

There are competing schools of thought on whether a software application should do one simple thing or be all things to all people. I tend to prefer to minimize the total number of applications and devices I have to work with, so I guess I fall more on the extensible side of the spectrum. Who am I kidding, I use emacs to check my email.

Nevertheless, even trying to repress my urge to converge, I still don’t understand why I can’t have a single app for messaging. I’ve read rumors that Skype may eventually support Jabber and that would be step in the right direction. If this bothers me enough I suppose I should contribute to Adium to get the changes in. Any other suggestions?

Keep your ORM away from my objects

J Aaron Farr on Tue, 07 Nov 2006

I’m increasingly of the opinion that object relational mapping tools are bad ideas. If you’re using a relational database, then use a relational database, don’t try to hide it or treat it like an object database, because it isn’t and ORMs are an incredibly leaky abstraction. My real objection comes down to this—don’t let your object model and your persistance mechanism mix. They’re two separate concerns. If you’re using OO, then get your object model right and don’t clutter it up or compromise it by mixing in persistance issues. I’ve seen way too many models where structure was sacrificed because of some odd ORM constraint that made life difficult to do it the right way. This is why I perfer a tool like iBatis which lets me use a relational database properly and still easily convert SQL results into objects without pain.

I could go on and on about ORMs, but I’ll leave more of that rant for later. But in all seriousness, if you’re using Hibernate or JDO or whatever, check out iBatis and, oh, get over your irrational fear of SQL. You’re using Java! Compared to that SQL is a walk in the park.

plants