A programmer who snoozed through the better part of the last decade or two might not know about object-oriented programming. The rest of us have had it up to our tushies in objects. I am actually somewhat sympathetic toward the van Winkles of the industry, because in 1986, when I stumbled back into the computer field, object technology was a star on a meteoric rise, while a decade earlier, when I had last absented myself, object-oriented programming was an obscure brown dwarf hidden away in the cosmos of nebulous computing techniques. Trend spotting is surprisingly easy when you peek once a decade or so.
Not that object-orientation is particularly new. Although some writers have credited the failure of structured methods for the genesis of object-orientation, in truth, structured programming and design arose right alongside objects, slithering out of the same primordial swamp of unstructured methods. Dijkstra, Constantine, Kaye, Dahl, and Sutherland were all working in parallel in the late 1960s and early 1970s, devising and dispersing the core concepts of these new ways of thinking about programs and programming.
By the mid-1980s, the concepts of object-orientation were well established, although not necessarily well understood. Of course, there was no shortage of skilled early adopters who could OOP their way through any problem. There was just a shortage of people who could give clear explanations. According to the rhetoric of the time, you had to live objects to learn to think and design in terms of them.
“How does an object compare to an information cluster or a module with informational cohesion?” asks the earnest student.
“Look,” responds the impatient instructor, “I told you to forget about that old structured stuff. It didn't work. Unless you cleanse your cortex of these things, you'll stay confused.” (Meaning, of course, that the teacher didn't know what the student was talking about, so shut up and listen!)
Many of the early pedagogues and demagogues of OO preached that the only route to objective effectiveness was to give up the ways of the past, to forget everything you ever knew or thought you knew about software engineering and learn a whole new paradigm. You had to start over, with a blank mental slate.
As if that were possible. What they advocated had more the ring of religious conversion than of learning new technical skills and concepts. Some gurus of objects still preach that way. Get them while they're young and untainted by procedures and you can make them true believers. Or so the evangelists claim.
Of course, as I quickly learned when I first took up the OO cause, many of those early proponents had to take this evangelical stance. Knowing nothing about structured methods or relational data models, they could not comment intelligently on the relationship of these concepts to OO and so could not risk getting probing questions from their more experienced students. When they did speak of the then-current software engineering practices, it was to attack them, playing an easy sport of shooting at targets that were carefully constructed of structured straw.
A certain fuzziness of definitions and a glaring lack of consensus on what constituted the core concepts of OO did not improve the plight of the poor pilgrim seeking object-oriented enlightenment. With time, though, things jelled, so that today there is fairly widespread agreement on the essential vocabulary and concepts of object-orientation.
Object-orientation is a lot of things. For some it is a way of making a living, for some it is a way of life. To understand object-orientation in its full glory you need to appreciate not only encapsulation and implementation hiding, but inheritance, delegation, genericity, dynamic binding, and polymorphism. (And people say the structural revolution foisted too many new terms on the field!) All of these concepts represent important aspects of the paradigm and its practice, but the real reason that objects have a secure future in software development is much simpler.
Not too much of the subtlety of object-orientation can be captured in a short essay, but the real peopleware issues are actually quite simple. (Even as I wrote this, I could hear the click of keyboards preparing the protesting email that would soon flood my in-box.)
Forget the hype of the true believers who tell you that OO is a new paradigm for thinking about problems. It's just like a “new, improved” breakfast cereal—it's all about better packaging. Classes, which are the essential component of object-oriented programming, are just improved containers for code. Object classes have a number of advantages over functions and subroutines. First, classes are large, economy-size containers, and bigger boxes means bigger systems can be built from a given number of components. Even though object classes are bigger, they look smaller and simpler because, cleverly, they tightly pack all the things about a single idea, such as ComputerCustomer or LaserPrinter, into one neat bundle that is easy to recognize and haul around. Yes, you do throw data and procedure into the same box, but it's the right data and procedure, the stuff that belongs together in the same box.
The box even bears a comforting label that sounds a lot like the real world of clients and users, which is the second major advantage of objects. All else is bonus goodies in the bottom of the cereal box. As OO pioneer Brad Cox was wont to say to anyone who looked in his direction with the vaguest hint of interest, the OO revolution in packaging is exactly like the transition from discrete electronics to integrated circuits, that is, from transistors to chips. It's a small difference that makes a big difference
I'll leave the rest of the details to Roland Racko, Meilir Page-Jones, and other real OO gurus who can demonstrate in their columns and books that even OO in all its glory doesn't have to be difficult, even for rusty old minds thoroughly tainted by structured methods.
The bottom line on object-orientation is that it is such a rousing good idea at its heart that eventually it will be virtually the only way serious software is developed. So, unless you only develop silly or stupid software, sooner or later you will get oriented. Good sources of object-oriented advice and knowledge abound.
If you are a programmer at heart, you will want, as is your bent, to cut some code. In the right language, this can be very instructive. The right language could be almost anything, but it's probably Eiffel, a language that deserves to be more widely known and more commercially successful than it is. Arguably one of the best-designed languages ever developed for engineering software, Eiffel is the virtual antithesis of the far more popular C++. Eiffel makes it easy to learn to think and build with objects while C++ makes it easy to fool yourself into thinking you've changed even while you're serving up the same old Shinola. Eiffel is clean and compact, C++ is another story. Within Eiffel, it is easier to program well and harder to do dumb things. Granted, Eiffel should be available from more vendors on more platforms, it could benefit from a viable and versatile visual development environment, and its tools should support established methods and notations. Native code compilation would probably help, and it wouldn't hurt if some of its supporters were less bristly. Smalltalk is bigger, Java is the brew of the day, but still, Eiffel is a language with a lot of friends. (Je suis ton ami, Bertrand.)
For years, my recommended OO primer for programmers was from the man who finally made structured design accessible to mere mortals. What Every Programmer Should Know About Object-Oriented Design (Page-Jones 1995) was not the first book on the subject, but it is never too late for someone to write clearly and well about a complex subject. (Now, that book has been superceded by an equally good tome from the same author, Fundamentals of Object-Oriented Design (Page-Jones 2000)).
So, get oriented.
From Software Development, Volume 3, #6, June 1995.