Howi Learned To Love Objects
Howi Learned To Love ObjectsFrom MostProgrammersDontGrokObjects:
So how did we come to grok objects?
Speaking from personal experience, I never really learned to program until I had been at my first job (software engineer working on an SNA stack project for UNIX) for a year. I had written code for 10 years prior to that ... but I wouldn't call it programming ;)
I would say that I discovered objects. A lot of our work was data-driven (it is, in a comms stack) so we had a large number of C structs. I grokked that I could write any program I liked, if I could just define the structs for it (until then, many programs seemed mysterious to me).
From that day on, all my programming began by defining the structs. I worked on several projects (at work and in my spare time) and they all went rather more smoothly than before. I noticed an increase in productivity.
From that, I went on to realize that many functions "belonged" to a certain struct, and that function pointers inside structs could make things behave differently depending on their "class".
Of course, they had! And when I first found Stroustrup's C++, it was almost a religious experience (although SmallTalk is closer to the object model I had in mind originally, C++ speaks to my need for efficiency and since I had already written a C compiler and was thinking about how to extend C to support objects, I found Stroustrup's approach extremely clever).
So, although this was a long process, I feel spoilt in that I never had to be persuaded that OO was a good idea - it gradually became obvious to me.
The frustration for me is that I work in the games industry and MostGamesProgrammersDontGrokObjectOrientation. This means my progress in C++ has been slow - a tool here, a hobby project there. I took 3 months off between jobs just last year, and had my very first experience writing an MFC application in C++. It was great fun, and I ended up with an architecture I was quite pleased with ... after refactoring and refactoring until I got there. I noticed certain patterns in my approaches. And only then did I discover the DesignPatterns and ExtremeProgramming movements.
Does anyone have radically similar - or radically different - experiences of coming to terms with objects?
... and is there a "next" movement that I will discover by hard work and effort which I could simply read about today? <g>
-- EddieEdwards
I started out similar, except that the "structs" were relational tables instead of code. It later grew into a fondness for TableOrientedProgramming. -- top
Personally, I came to OO "by example", in a slightly backwards way. It must have been about, hm, 1988, and I was using/playing a game called Repton Infinity. For those of you that know Boulderdash, that's basically what Repton was: A grid-maze with gravity, collect the diamonds, dodge falling rocks.
Repton Infinity was the fourth in the series. Repton 3 had introduced a feature that was something of a novelty: As well as playing the game, you could modify it with a built-in editor, that let you alter the bitmap graphics and the maps. Repton Infinity extended this -- in what seemed to my 12-year-old mind to be raw magical power -- to allow you to edit the behaviour of the game as well as its appearance.
I'd been programming for about 6 years at that point, in the only language available to me on my 20 pence a week pocket-money: BBC Basic. As Basic implementations go, it was a pretty good one -- support for functions with nice long names and so on (bear in mind BBC Basic was written in 1981, when ON ... GOSUB was the height of sophistication on home computers! *shudder* *grin*). But it had no concept of structs and only the crudest form of pointers (ie PEEK).
So when a year or so previously I'd written my first "real" game (Breakout) I'd had to simply pick variables for the X, Y, Xdelta and Ydelta of the ball, and the X of the bat, and just process them "by hand" (so to speak).
And I knew I needed something more powerful, something more generic/abstract, but the language did not have the tools to support this -- indeed, I had no conceptual framework to even imagine quite what it was I needed, at the time. And this is why Repton Infinity seemed like magic.
But it gave me a clue: It was, crudely, object-orientated. Each square on the map contained a sprite, and each sprite was an object. Each object had a "process" method that was called once per game turn, and you could define a couple of extra event-handling methods, such as "on collide".
The idea of "each object processing itself", sowed the seeds, and I tied my juvenile brain up into knots trying to see how to do it in Basic with no structs or function pointers ;}
Aaanyway, to cut a long story short, a couple of years later I finally got access to hardware more powerful than the BBC Micro's 1mhz 6502 processor, and with it, Borland Turbo Pascal, where I cut my teeth on structs ("records") and pointers, and the ideas started to crystalise. Then they released a new version of TP ("now with objects!") and, with all that previous subconscious brewing of ideas, I had the "Aha!" moment almost instantly. I was a happy, happy carnivore :}
And that's how I stopped worrying and learnt to love the object. ;}
(phew. aren't you glad you asked? :P )
Anyway, what I'm seeing so far is that people who get close & snuggly with their objects are those of us who came to the concept over time, instead of having it thrust upon them by a zealot :-}
-- CanisLupus
I'd seen adverts for Actor which claimed, "Write a drawing program in 3 lines of code!" or whatever it was - I was unimpressed because it seemed clear all the work was done by a library and you have libraries with C. One day I read through a Smalltalk manual and grasped that here, in fact, were better tools for building libraries.
That was, what, 15 years ago? I believe I still have things to learn about objects. I'm reluctant to say, "I grok objects" because I still come across people who seem to grok them better. -- DaveHarris
I started out using ZX-81 BASIC, then Apple ][ BASIC. Then I got to learn C in a summer internship at Electricit� de France; I was still dicking around with C by the time of my second summer internship... with InteractiveSoftwareEngineering?, home of EiffelLanguage and BertrandMeyer. Of course I had to read ObjectOrientedSoftwareConstruction first. And then, of course, I got to be around BertrandMeyer and his team for six weeks. I hardly need to finish the story... I had to go through two RealJobs? before I was finally able to code in OO languages exclusively (C++ and Java), but the pattern had been firmly imprinted in my mind. -- LaurentBossavit
I think I've always loved objects, even before I knew that's what they were called. My first Basic and assembly-language programs I wrote for my Atari 800 were all structured around the "things" that the programs dealt with. Later, in college, I learned about "abstract data types", which seemed to be what I was doing all along. My Pascal, C, Fortran, Lisp, and ML programs were all somewhat object-oriented. When I learned about Smalltalk and C++, I finally found languages that let me naturally express what I had been doing all along.
I still can't understand why other people don't "get" objects, as I can't understand how people can do it any other way. When people ask "What are the benefits of OO?", I never have a good answer, because to me it's like asking "What are the benefits of mathematics?" or "What are the benefits of chocolate cake?"
I wrote my first object oriented program around 1990 with a proprietary IBM language that was very similar to Smalltalk. The IBM engineer that taught me OOP explained it like this:
Think of yourself. You know you exist. You feel things. You know things. You can do things. That's what an object is.
Within thirty minutes I was so hooked. However, I learned one more lesson from this engineer that really cemented the way I think about OOP:
Just like you, an object has a life. It is born, it does useful things, and then it dies. Some objects only live for a fraction of a second, but most objects have a long and prosperous life.
It was fantastic. Things just clicked in my mind and I saw all of the options this fantastic new way of programming gave me. Plus, the way of thinking of objects as real living things seemed so logical and normal to me.
At the time I was almost exclusively writing games and I found C++. Then I learned something that greatly saddened me: In C++, objects always died when my programs stopped.
This didn't seem right to me. I was exposed to OOP, for all intents and purposes, via Smalltalk. The tool I used at that IBM lab had an image. When I created objects, they lived as long as I wanted them to. It matched what my mentor told me; C++ didn't quite match. Still, I was writing games and I needed speed. I quickly rationalized that -- in most cases -- I didn't *need* the objects to live beyond the end of my program's execution. I wrote code in C++ for games and Smalltalk for everything else. Every time I went back to C++ I always felt a twinge of loss and guilt for not using Smalltalk.
Then, in 1995, I found Oak. I was very excited because I thought: finally! A language that was more like Smalltalk but similar enough to C++ that people might take it seriously. Again, I was saddened when Java was brought to the world. Java had the same limited notion of objects that C++ had. They all died when the program stopped running. How stupid was this!? This is not what objects were meant to be.
I only dabble in games now, so I haven't used C++ much since 1998. I use Java and C# on a daily basis. I use Smalltalk a great deal as well, though there isn't much paying work. As far as I'm concerned, Smalltalk is the only language that got OOP correct.
This is why I'm such a huge fan of OODBMS'. It isn't that they're databases; quite the contrary. It's that they fix the flaw in most OOPLs that exist today. They bring languages like C++ and Java into line with what I believe object oriented programming is all about: living, breathing, useful objects that -- in most cases -- have long and productive lives. -- JeffPanici
How I Learned to Love Objects
For me, the turning point was when I realized that object oriented programming was really just a set of rules for packaging functions.
I started in the embedded development world doing hardware development and quickly became involved in microcode and assembly language programming. Eventually, I migrated to C. My first introductions to object oriented literature sent me running, however, the philosophical nature of much of the work (Bertrand Meyer, in particular) really turned me off. I wanted to learn about programming not taxonomies, for goodness sakes!
The turn around for me was the book Class Construction in C and C++, Object Oriented Programming Fundamentals by RogerSessions. This book derived many objected oriented C++ constructs from C code. Suddenly, OO was no longer "the new paradigm," but merely a natural extension to procedural programming. Mentally, I was now ready to objectively evaluate how OO/C++ features improved my code.
For those fighting the transition from C to C++, I would strongly recommend the Roger Sessions book. It is strongly focused on teaching, but may not be applicable outside of C/C++ programmers.
First, I created an object. For a while, I worried... said things like 'I am become death, destroyer of worlds' - all very angsty. Then, I stopped worrying. Finally, I learned to love it.
Like many I backed into OOP as I did programing. I was taught with Pascal and strict Sructural programing, and at the time I had only a few bad habits which were easliy broken. I saw the benifits of managing complexity in this way, and later as I learned data structures (ADT's ) I saw the beginings of the notion I would later call 'objects'. To this day I think of an object as a set of properties, and try to get others to do the same,but the best, and most pragmatic, advice I ever got on understanding objects was this : " Object orientation is a way of managing complexity". I wish I could recall where I read or heard it. By shifting the stress from what they are ( theortical ) to what they are for ( pragmatic) I was able to avoid geting tied up in metaphysical questions and put objects to work.
Marc Grundfest
EditText of this page
(last edited May 30, 2008)
or FindPage with title or text search