Fog Creek Software
Discussion Board




The OO programming benefit no one talks about

Hi,

I'm very new to OOP. I've programmed in VB 3 and 6. 


The way OOP has always been explained to me, the benefit is that you reuse code, so you save time by not needing to rewrite THAT code.  However, I think that's BACKWARDS...


I've now found that the OPPOSITE is true. The benefit of OOP is reusing all of the NON OBJECT CODE.

HERE'S WHY...
Suppose we have a program composed of Non-object code and some Objects. Now, lets say the Objects are 20% of the code in our program.

Now, lets say we write 10 more programs of equal length. If we reuse all our objects, we save about 20% of the coding.

This is how I've always seen OOP benefits explained. You reuse the object and save code. HOWEVER, after reading Design Patterns Explained (by Shalloway/Trott) it seems that the REVERSE is true...

The real benefit of OOP *seems* to be that if we can reuse the non-object code to create a new program by CHANGING THE OBJECT, then we save 80%, not 20%.

As the authors explain:  you encapsulate what CHANGES into an object.

I realize there are lots of other benefits of OOP.  However, I'm a pragamatist.  I've always looked for a compelling benefit of OOP or a single programmer. I think this is it.

QUESTIONS:

1.  Am I on the right track?
1a.  Am I hearing OOP proponents (OOPPs?) correctly when they state the benefit is reusing the obj code?

2.  Is the benefit of reusing the non-obj code really a much bigger advantage than the oft' touted reuse of the obj code?

3.  Am I being insightful here, or obvious (or obviously stupid? if so, why).



______________________________________
EXAMPLE BELOW
SKIP IT, if the above was clear.
______________________________________




The example below is from a real program I wrote using the above methodology, although I didn't realize it was an OOP approach.

I always thought that the benefit of OOP was to create an object which is reused.
HOWEVER, I'm reading Design Patterns Explained by Shalloway/Trott.  It suggests that it's sort of the OPPOSITE. Let me explain.

So if I have a program that shows users a picture and lets them type the word for it, then if I want, later, to let them CHOOSE an answer instead of typing, then the INPUT method is what is changing. So, I create an object (objINPUT) which can be EITHER a textbox OR a list box. To the PROGRAM they look the same. SO.... when I write a new program that now needs to let the user CHOOSE instead of typing, I just change objects.

Notice that we're not reusing the OBJECT. We're reusing everything that is NOT the object. It's actually a much BIGGER savings.  (If the object is 1% of my code and I use it in 10 programs, I save 10% of my total code.  If I, instead, am able to reuse the PROGRAM by swapping out the object, I save 99% !!!

This is actually the way we wrote our programs, but we did it with case statements (switch you c++'ers) ex:

select case ProgramTYPE
  case  Fill-in-the-blank
        textbox.visible=true
  case multipe-choice
        listbox=true
end case

These cases are repeated throughout the program.  Each could be replaced by a simple:

objInput.MakeVisible
  .. then the Fill-in-the-blank object would show the text box.
..... the multiple-choice object would show the list box, etc. etc.

.... we might extend later by creating a multi-multi-select object that has SEVERAL list boxes.

Peter Parker
Thursday, June 05, 2003

You're right on the money. You've discovered the benefits of polymorphism. For some reason, the OO salesmen really pushed inheritance, but polymorphism was always the big win.

I look at it this way: functions let you re-use the function that gets called.

Objects let you reuse the code that does the calling.

And it is good.

Chris Tavares
Thursday, June 05, 2003

If you're reading Shalloway and Trott you're on the right path.

I don't understand why this book isn't more widely celebrated - perhaps it's not as hardcore as the GoF book, but I think it addresses the fact that OO is generally poorly understood.

Walter Rumsby
Thursday, June 05, 2003

"I've now found that the OPPOSITE is true. The benefit of OOP is reusing all of the NON OBJECT CODE."


I love these moments :)  nothing like the moment of realization...

FullNameRequired
Thursday, June 05, 2003

And, with enough time, you'll probably reduce that 20% to 10% then to 5% and finally to 1%. OOP is highly overrated. It has some place in GUIs and various other niches, but as a general programming technique (as practiced today), it sucks.

<sarcasm mode=on>OOPs greatest benefit is, perhaps,  job security. Everyone will scorn goto-spaghetti people, but everyone adores class-spaghetti people, because it's OOP and supposed to be good.</sarcasm>

Free some time, (say, an hour or two), read [ http://www.geocities.com/tablizer/oopbad.htm ] even though you will probably dislike the presentation style. Then go back to your project and try to see if you agree or not. Then, a month or so later, read it again.

You'll learn a lot.

He-who-would-not-be-named
Thursday, June 05, 2003

For me, OOP is all about polymorphism. I ditch hype.

Leonardo Herrera
Thursday, June 05, 2003

That article on geocities is worth a looking, although I got bored after reading a few points.  One point that did strike me, is I tend to agree that oop is better for modelling internal programming constructs rather than necessarily real world objects (however the article goes on to say because not all books explain it that way or some use real world objects in examples, oop is flawed blah blah)

What I do know is my life has got easier when using oop.  My own path was non-oop to oop (Turbo Pascal latter versions) to non-oop (C) to oop (C++)

I agree polymorphism is a major benefit of oop

I think oop benefits get undermined when you get people who get religious about 100% oop. 

As for persistence, relational/OOPs mismatch.  I'd say I prefer to make an OOP model of a relational database, rather than trying to squeeze a pre-existing OOP model into a relational database which doesn't really fit.  Start relational and work to oop, rather than vice-versa.

S. Tanna
Thursday, June 05, 2003

To the first poster, you're right that sometimes when people think of reuse they only think of reusing the called code.  But it works both ways.  You can reuse the calling code as well.

This is like the distinction between a traditional library and a framework, more or less.  In a standard C-style library, you call the library's functions to do work for you, printf or whatever.  In a framework you fill in the functions to be called.  That is, you're reusing the calling code.

Another way of looking at it is that there isn't always a good reason to make this distinction at all.  OOP promotes orthogonal designs.  That is, changing one thing shouldn't affect the other.  That's what interfaces are for.  You can change the calling code, or you can change the called code, and as long as they agree to the same contract/interface, things still work.  It's reuse either way.

So in short:

1. Yes 1a. Not really, most OOP proponents recognize that both kinds of reuse are important and beneficial 2.  I don't think you can say either is more beneficial, it depends on the circumstance 3.  Yes, I think this is a key observation toward fully understanding OOP.  I think this has dawned on many experienced programmers at some point.  You go from the traditional library reuse to the framework style reuse.  But after awhile you realize they are part of the same concept.

Andy
Thursday, June 05, 2003

"Then go back to your project and try to see if you agree or not. Then, a month or so later, read it again."


but..but..but....the man is talking a load of bollocks.

whinging on because sql databases are not designed to work with OO programming?

bleating about protocol coupling...that mostly occurs during the design phase before you work out exactly what should go where...if he never got any further than that, no wonder he doesn't like OO programming....bottom line is that if you cannot separate objects out cleanly then you should re-examine your divisions..

?? part of it reads like he is seriously comparing OO programming and SQL?  talk about apples and oranges...

who would take this seriously?

FullNameRequired
Thursday, June 05, 2003

Actually it sounds like a nematode worm complaining about how all the trilobites are sucking up all the food these days.

Out evolved.

Simon Lucy
Thursday, June 05, 2003

>Actually it sounds like a nematode worm complaining
>about how all the trilobites are sucking up all the food
>these days.

Not the best example. Trilobites - extinct, nematode worms - exist in huge numbers all over the world.

I agree with your sentiment, though.

Andy
Friday, June 06, 2003

*  Recent Topics

*  Fog Creek Home