Fog Creek Software
Discussion Board




OOP Paradigm Shift:  A Different Perspective

In a recent thread Augusto asks:

"Is it really difficult to do the [OOP] shift? Can anyone recommend a book or net resource to help this? The problem isn't the language itself, but how to change my mind. Maybe it is an IQ issue?"

The rest of the thread suggested to me that the majority of people who started out coding procedurally have had difficulty with the paradigm shift.  I imagine that a lot of those people are really amazing programmers.

This wasn't the case for me.  I started off in C, and when I got my first taste of OOP using C++, I couldn't believe that I'd ever done without it.  It was truly one of those "eureka" moments.  I never wrote another line of procedural-type code in my life, and to this day I wake up sometimes with the feeling that, "Hey, I never have to deal with that spaghetti code procedural crap ever again.  Ain't life grand!"

I don't think it is - as Augusto calls it - "an IQ issue", because lot's of the best programmers I've ever met have described the same difficult shift. 

Two questions:

1.  Are there a lot of other people who've had this "eureka" experience with OOP?

2.  If you're one of us, what is it about our brains that is different from the majority?  Is it just like being left-handed where you're just born with a natural tendency?  Or maybe something else?  (BTW, before I did my CS degree, I got a Math degree, and I always had a feeling that this is how you're trained to think in Math:  abstract all the detail away.  Maybe if you spend your formative years very close to the hardware (CS or CompEngr), instead of in theoretical la-la-land, it's a bad strategy to abstract anything away because every machine instruction counts.)

anon
Wednesday, May 07, 2003

"Design Patterns Explained: A New Perspective On Object-Oriented Design" by Alan Shalloway and James Trott (Addison-Wesley)

http://www.netobjectives.com/dpexplained/dpe_book.htm

(There was a sample chapter online which I can't find right now - maybe try the "Look Inside" feature on Amazon.com)

For instance, this book explains why you should favour composition over inheritance and why you should program to interfaces and not classes. GoF states that the above is their recommendation, based on experience, DPE does a better job of explaining why you should follow those guidelines.

Walter Rumsby
Wednesday, May 07, 2003

I had an anti-eureka experience with OOP.  After all that I heard, I couldn't believe that the concept was that simple.

Alyosha`
Wednesday, May 07, 2003

"Hey, I never have to deal with that spaghetti code procedural crap ever again.  Ain't life grand!"

There is nothing about procedural code that makes it inherently spaghetti like, and you can have terrible spaghetti with an OO approach too.

I'm of the school that says OOP is just a natural extension from procedural style programming.  Many programmers of traditional procedural style languages used OO techniques long before they had heard of OO.  For those programmers there was no big paradigm shift to OOP, just adoption of tools which better supported familiar patterns.

For example: once you have a structure in C its natural to associate a set of functions with it, so data/state is associated with a set of functionality.  OK, so in C++ you add a bit of syntactic convenience to this pattern and call it a class - nice but not revolutionary.

Another one: Polymorphic behaviour was achieved in C using function pointers, C++ makes this more convenient using virtual methods.

Just my 2 cents.

Peter

Peter McKenzie
Wednesday, May 07, 2003

My reaction was that OOP was just a lot of jargon to wrap around what I'd been doing for twenty years.

But, then I've always prefered functional and declarative to procedural.

Anonymous Coward
Wednesday, May 07, 2003

I came across OO around 1994 and when it fell into place it was a great moment. I realised that my head had been dealing with objects already, but I hadn't had the tools to bring this out neatly into code.

I should also add that learning formal OO techniques (polymorphism, inheritance etc.) was important to complete the whole learning cycle. Ideas which had been hovering around the right slots all snapped into place. It took at least one failed (personal) OO attempt to understand the approach, but I have never looked back.

I cannot avoid thinking in objects now, no matter what language I am dealing with.

Joel Goodwin
Thursday, May 08, 2003

All of the OOP books that I read said that they'd be a "eureka!" moment when the light bulb went on but I didn't really find that that happened. The closest I got was probably when I first learnt about polymorphism.

John Topley
Thursday, May 08, 2003

I just use it to give me decent types and not have functions operating on specific data lying around all over the place.  I always feel disconnected when people do a lot more with them.

Oddly enough, Benjamin Pierce in the OOP chapter of his book on types, claims that "classes in most languages tend to become the dumping ground for all language features that have anything to do with large-scale program structure."

Tj
Thursday, May 08, 2003

In 1990 when I was a Turbo Pascal programmer and my world was all procedural, I read some magazine articles about OOP, and it made absolutely no sense to me. Objects send messages to each other? Smalltalk? Even integer numbers are objects? What has that got to do with computers?

After that, I gradually learned what OOP was *really* about: data types, records and functions. I think I finally "got it" when I saw some OO code which showed a function and mentioned the "self" pointer. ;) Yeah, I think it was the term "self pointer" that was the key for me.

Today I'm a Delphi / Object Pascal programmer, btw.

YF
Thursday, May 08, 2003

Conceptually, when I read the Turbo C++ programmer's manual the first time, I went "Wow, this is awesome!  This makes total sense!"

I've spent the years since then learning how much there is to learn about development.

Eureka moment?  Definitely.  Did it mean anything?  Not really.

-Thomas

Thomas
Thursday, May 08, 2003

Using Borlands OWL (Object Windows Library) beat the hell out of SetWindowsLong and trying to figure out the arbitrariness of  Windows name-space pollution.  But that was years ago, everything is fixed now.

Nat Ersoz
Thursday, May 08, 2003

I can really advise you to take a look at python.

besides the fact that python is a really nice programming language, it can be really helpfull in the OOP learning process. because all of the oop concepts are so easy to apply in python, you can focus on the theory and not the language.

Gumuz
Friday, May 09, 2003

I had to chuckle at this statement:

"For example: once you have a structure in C its natural to associate a set of functions with it, so data/state is associated with a set of functionality.  OK, so in C++ you add a bit of syntactic convenience to this pattern and call it a class - nice but not revolutionary."

This is not what C++/OOP is all about, and if you think this way, you clearly don't "get it" yet.  Maybe this is why so much C++ code I see is so bad?  I wonder what percentage of C++ programmers agree with the quote above?

Spaghetti Rustler
Friday, May 09, 2003

You have a good point. To me, the revolutionary thing about OOP was polymorphism. Encapsulation (adding functions to a struct) is just nice. Inheritance is rather confusing and it's not obvious why you'd need it.

But once you get polymorphism, that's when you get that "eureka" moment and all this OO drivel starts to make sense.

Chris Tavares
Friday, May 09, 2003

I don't know, Spaghetti Rustler, it seems to me that painful OO programs come not from those that treat objects as a tidy way to package functions related to a common data type, but rather it comes from those who create assinine relationships between objects.  In procedural programming if you are good about limiting the use of globals it is pretty clear how the data flows.  You can see what is coming in and out of most function calls.  Objects are "great" way to enable huge reams of data to be visible to large masses of code, such as "I'll pass a pointer to my document object to each of my view objects!", or even better, "My document will contain a pointer back to each of my views so that the other views will be able to find them!"--Great, now the entire system is visible to the entire system!  It's like everything is a global, only the global variable names have a lot of -> in them.

Keith Wright
Monday, May 12, 2003

*  Recent Topics

*  Fog Creek Home