Wednesday, September 22, 2010

Object-oriented Coding

Object-oriented coding is easy, in some sense. 

First you use functions. Repeated code disappears and the problem of "what do I call THIS variable?" disappears. Redefine the context, and suddenly giving nice, coherent names is easy. That's pre-OO but always the first step. No methods, no OO.

Then you start to generalize. When you generalize well, things start to fall into line. Messages are being called on "this" or "self" instead of that other thing. And code gets deleted from subclasses.

Then at some point you look at the monster base or superclass or the whole hierarchy and you say, "this cannot be good." So you start to delegate some of its work to other classes. If you do it right, they have a small bridge between them (and not a "Spaghetti Junction"). Then you start to work on the new structures that develop.

And as you add code, you continue to do this, and crystalline or fractal-ish structures form. And then you say, "my God, I've got a total mess. Any code could be anywhere." But of course that didn't happen, because you've got people yelling at you from every direction to do MVC or some super-structure to organize. But isn't it obvious, really, that you need to organize your stuff? Coding is 10% brilliant solutions and 90% organization.

And THAT the fizz-buzz problem does not test.

No comments: