Programming borrows a lot from the construction industry. Many programming terms derive from construction: hacking, builds, development, architecture, scaffolding, frameworks, and dozens of others. But in some ways, programming has an element of power beyond construction.
Take, for example, a building. When you build a building, you start by pouring a foundation. On top of that, you construct a skeleton, add walls, a roof, sheetrock, siding, and all the plumbing and electrical. Each one of these details needs to be built by somebody--all four walls of each room needs to be framed in, wired, and finished.
In the world of programming, however, you really only need to build one wall, and then the computer can create as many copies as you need. So when building your program, you might create a "wall" class, which is comprised of a bunch of two by fours, sheathing, sheet rock, wiring, and outlets. You might give your wall a set of properties: width between studs, overall width, overall height, position of outlets, the number and dimensions of windows and doors, etc.
Once you have a wall defined with a bunch of appropriate variables, you can then work up to defining a room. Your room might have four walls, with windows and doors in particular positions. Obviously, there's new levels of complexity here, but you don't have to build every single wall if you can just specify a new wall with particular characteristics.
Now that we have a generic room, we can extend our room model by creating specific types, or sub-classes, of rooms: bedroom, bathroom, kitchen, utility room. And then we can define an apartment as a particular combination of rooms, and an apartment building as a particular combination of apartments.
A powerful program is one that allows you to say, "give me an apartment building with this many apartments of this base floorplan, and put it here." A few lines of code specifying any details that vary from your standard, and you're done with the basic system--you can start creating custom trim.
Object-oriented programming is powerful because it lets you start with a basic model, and extend it to create variations. Each variation (or subclass) inherits all the hard work that went into the underlying class, but adds only the details that make it different. The bathroom extends a generic room by adding plumbing and fixtures.
To me, this ability to inherit properties from other objects is the main reason to write object-oriented code. Some languages (like Java) force you to do everything in an object-oriented way, which strikes me as less practical--you need to find design patterns that work with that model to accomplish what you're trying to do. But object orientation provides a powerful way of modeling a system.
When I review code, I'm looking for object orientation used in an effective, sensible way. Each real world object being modeled in a system should have a corresponding class in the underlying system. Classes should extend some basic data class to avoid repeating the same methods in a bunch of separate classes. Code should be built up into units that can become parts of other units, so that individual chunks can be kept small and understandable. If any PHP file ends up longer than a thousand lines, I start looking for ways of simplifying, streamlining, sharing code with other modules. If any individual method ends up longer than a hundred lines, it should be doing something extremely unusual that isn't necessary anywhere else.
The Unix architecture is often summarized as "small pieces loosely joined." Each identifiable chunk should be small and have a clearly defined purpose. Assembling these small pieces into a larger system results in great power while also allowing for reliability, security, and actually getting the project finished.
It's all a matter of scope. When you're looking at a wall object, you are working with two by fours, nails, and sheetrock. When examining a room, you're working with walls, a ceiling, and a floor. Programming should hide the details of lower layers, and allow the programmer to focus on the necessary detail for the scope of the module she's working on. The result is powerful code.
Why would you not need powerful code?
Pascal (and many others) is credited with the idea that it takes longer to write shorter code. This series of blog entries certainly illustrates the concept... The same principle holds true in code. If you're creating a web application that's never going to need revision, it can be much quicker to just write as you go and end up with some big long pile of spaghetti code. The instant you need to change it, or worse, somebody else needs to change it, fast, long-winded coding takes a lot more time to update.
As far as I'm concerned, the only reason to not take a structured, measured, powerful approach to coding is that you need something temporary working today, and don't care that you'll probably have to scrap it and do it right later.
How do you create powerful code?
Powerful code comes from structure. Frameworks deliver structure. This does not mean a particular framework is powerful for your application.
A skyscraper needs a much stronger foundation, and far better design to prevent collapse than a house. In programming, you can either use somebody else's framework, or build or grow your own.
Developers love building frameworks. It's fun to think of all the things that people might someday do with your framework, and build in a mechanism that provides useful ways of doing those things. The problem is, build in too many features to the framework and you just end up with a large bloated blob of code that nobody uses entirely, that nobody even knows how to use properly. Make your framework too small, and people end up having to do more work in the actual application.
The hot framework right now is Rails. It has a lot going for it--a solid philosophy of convention over configuration, auto-creation of all sorts of things like database tables you otherwise have to build yourself, and other features I'm sure you've heard about already from all the Rails developers out there.
Personally, I think frameworks like Rails are overrated, hiding too much of the implementation to be valuable. The perfect analogy for this is photography. If you take a basic photography course, you learn about the basic fundamentals: lens focal length, aperture, shutter speed, focus distance, and film speed. That's all you need to know to take great pictures with any camera--at least any that allows you to set these things manually. Most cameras these days try to automate all of this for you, and most of the time they do a reasonable job. But most cameras also have a whole set of special settings. My Casio has a "Best Shot" mode, designed to set the camera up for different scenarios: landscapes, portraits, evening shots, indoors, backlit, etc. Some of these modes do really sophisticated things, but is it better for a photographer to understand all the different programmed modes, or the fundamentals of photography? I would argue the latter--with an understanding of how photography works, you can operate any camera. With an understanding of the programmed settings of a particular camera, you're lost as soon as you move to another.
That's the problem with frameworks--you spend more time learning all the ins and outs and arbitrary ways of tweaking it, instead of focusing on the actual task at hand--taking good pictures. Then again, I prefer a stick shift to an automatic every time...
When it comes to frameworks, less is more. The simplest possible framework that fits your application requirements is the one to use. If you can't find one that fits, start with some simple data objects, an effective template library, and build your own, but don't spend too much time on it--let it grow as you need it.
In the grand scheme of things, I don't need a framework to create a database table for me--that's a lot of extra code for something that only happens once. But for all those things you do need more than once--for the walls, rooms, and apartments in your building, design with care and power in mind.
For more about power, go read Paul Graham's essay, Succinctness is Power. Then follow it up with Holding a Program in One's Head.
Add new comment