• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

OOP Is Much Better in Theory Than in Practice

 
Ranch Hand
Posts: 476
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
C is in Java, C++ out:
http://www.theserverside.com/tss?service=direct/0/PostNewsReply/postReply&sp=l31439&sp=F&sp=l154423
 
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
 
Alex Kravets
Ranch Hand
Posts: 476
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
you should read reviews on amazon for this guy's books.
 
Steven Bell
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I just love this quote:


A frequent argument for OOP is it helps with code reusability, but one can reuse code without OOP�often by simply copying and pasting.

 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, the guy admits that OOP is useful for GUI programming and for teams of more than one. He just thinks that "most programming" doesn't fall into those categories.

I guess it's a question of what one defines as "programming". I tend to agree that object oriented programming might be overkill for people who just need to put together a quick spreadsheet macro.
 
Alex Kravets
Ranch Hand
Posts: 476
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
true. But he seems to generalize that OOP is bad alltogether.


To keep your code bug-free, encapsulation hides procedures (and sometimes even data) from other programmers and doesn't allow them to edit it. Inheritance then asks these same programmers to inherit, modify, and reuse this code that they cannot see�they see what goes in and what comes out, but they must remain ignorant of what�s going on inside. In effect, a programmer with no knowledge of the specific inner workings of your encapsulated class is asked to reuse it and modify its members.


Isn't this the beuty of inheritanace? I take something that works and tailor it to my needs (if design permits).
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We have to admit though that OO can and often is abused in many ways.
Using OO for the sake of being modern (yes, I've seen it) when some other technology would serve better is just the tip of the iceberg.

I think we've all seen the arguments that OO allows code reuse?
Well, function libraries can do that as well.
And I won't even start about code reuse being a red herring as everyone here knows that code reuse is not something which happens a lot in practice.
Then there's pattern bloat. Think of layers upon layers of objects just to conform to patterns by designers who have learned to design in academia and don't know where to stop.
20 layer application anyone with factories for all objects that need to cross a layer boundary?
 
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Alex Kravets:
you should read reviews on amazon for this guy's books.


... his statements would have more weight if all script programmers were able to write such books.
Most apps aren't written by one person. Even simple apps are written by 1 person and then they want change and other person codes the change.
Part of my current projects consists in keeping alive some procedural heavy Lotus Domino apps. I am quite good in doing that, but it sucks and they'll be replaced by more OO-style, because maintainance/change costs are too high.

Agree 2000% that OO as such is not a holy grail for maintainable apps, but OO can help big way, so why not use it.

If OO wouldn't work "in praxis" (whatever that means). Why they included lots of OO in PHP4.

Real problem in IT are bold discussions like "OOP is much better in Theory than in Practice"
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To me, OOP helps writing code that conforms to he Open Closed Principle. With polymorphism it's much easier to provide injection points for changed behaviour while at the same time closing the code against modification.

Take JDBC as an example. How would this have been designed in a procedural way?
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja Preuss:

Take JDBC as an example. How would this have been designed in a procedural way?

In C, the library functions would have been declared (looks like a Java abstract function declaration) in ".h" header files that would have been common to all drivers and were included (equivalent to a Java import) by any client code. The driver specific code implementing these functions would have been placed in ".c" code files and compiled into binary implementations. The client's make file would have specified which implementation to link against.

Entities such as database connections would be handled through "opaque" pointers returned by some functions for passing in to other functions. "Opaque" means the client code is not supposed to use the value, just pass it into other library functions.

Not saying it's better or even as good as the Java JDBC approach, but it could be done, and quite cleanly at that.
[ February 03, 2005: Message edited by: Warren Dew ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The article ends with a link to the infamous tablizer oopbad pages. We've been there before. Sigh.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
In C, the library functions would have been declared (looks like a Java abstract function declaration) in ".h" header files that would have been common to all drivers and were included (equivalent to a Java import) by any client code. The driver specific code implementing these functions would have been placed in ".c" code files and compiled into binary implementations. The client's make file would have specified which implementation to link against.



If I understand correctly, this doesn't work when a system needed to deal with more than one database type at the same time?

Well, I'm sure that there is a solution to this problem in C, too. I just find it hard to believe that it becomes harder in an OO language...
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
depends Ilja.
The drivers could be loaded from shared libraries using a common interface.

If the vendor supplied drivers don't have a common interface (quite possible) an adapter pattern can be implemented without OO code as well to provide a proxy to the different driver implementations (similar to JDBC driver interfaces which serve as adapting proxies to the real database calls) as shared libraries which can be loaded at runtime as required and themselves load the real drivers.

It doesn't become harder in Java indeed. In fact it's at just about the same level of complexity.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeroen Wenting:
It doesn't become harder in Java indeed. In fact it's at just about the same level of complexity.



Yes, I think you actually more or less had to develop your own implementation of polymorphism?

It's totally clear that it is possible in C. After all, the first C++ compilers were not much more than preprocessors generating C code.
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
not sure if you'd call it that, though it would amount to it.
You'd get a dynamic library chosen at runtime implementing a fixed set of functions as defined in a headerfile.

So yes, you'd get some sort of polymorphic behaviour.

OO might make polymorphism a design paradigm but that doesn't mean it's impossible or never used in other languages.
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, yes, of course, the right tool for the right job.

I remember looking at the oopbad site a while back. This little gem from that site tells me all I need to know about the honesty of this guy's arguments:

"OOP is the greatest boon for those who like to write bloated code. I am not saying that all OOP code is bloated. But, something or someone is encouraging the practice of taking the most amount of code to do the fewest things. Further, OOP has added new ways to write bloated code that procedural has a hard time competing with. Hypothetical example for adding two numbers:"



And, as mentioned elsewhere, this statement is the most telling: "one can reuse code without OOP�often by simply copying and pasting." So Mansfield rails against the (ludicrously fabricated) bloat code above, but thinks it's ok to introduce rampant, costly duplication?

It sounds like I can blame Mr Mansfield and his ilk for the idiocy of procedural systems like those I encountered at MCI (v1.0). To add a simple, single field to a report was going to be billed back to marketing (who drove the requirements) at a cool million bucks. Typical garbage CICS code with duplication everywhere.

-j-

http://www.devx.com/opinion/Article/26776
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's interesting that you can do a flavor of polymorphism without OO. In COBOL you can call a program by having its name in a string. There is zero compile time checking that the module you're calling exists or is at all compatible but it's dead easy to plug in alternative behaviors . This is an essential part of CICS application architectures.

In the late 80s IBM did a major release of CICS saying they had done OOAD with a non-object assembler and PLI implementation. The main visible difference was they replaced direct access to many data structures with APIs. Certainly a good step.

I liked it whan Ed Yourdon called OO "structured structured programming". I first saw it as better facilitation and enforcement of things we already knew were good. At the time, OO was an incremental step from the kind of encapsulation that I'd been doing in Turbo Pascal.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I like Robert C. Martin's analogy:

Structured programming is discipline imposed upon direct transfer of
control.

Object-oriented programming is discipline imposed upon indirect
transfer of control.
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


While I don't agree with what Mansfield seems to think is the right way to code in general, I do agree with him that the above is the kind of bloated abomination that often seems to happen when people insist on using objects for everything. It's slightly exaggerated, but not by all that much.

Just because indirect transfer of control is better than direct transfer of control in some situations doesn't mean it's better in all situations.
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
While I don't agree with what Mansfield seems to think is the right way to code in general, I do agree with him that the above is the kind of bloated abomination that often seems to happen when people insist on using objects for everything. It's slightly exaggerated, but not by all that much.

Just because indirect transfer of control is better than direct transfer of control in some situations doesn't mean it's better in all situations.

I don't think anyone here has suggested OO is better in all situations. And in general, you can produce an elegant OO solution that is not unnecessarily bloated due to its being OO.

Oddly, the above pseudo bloat code looks like some sick translation of assembly language; I've never come across something quite that bad. I've come across different kinds of bad, but not due to programmers insisting on pure OO.

Plenty of "bloat" code exists in both OO and procedural code. Let's not forget it's the C geeks who champion obfuscation contests.

-j-
[ February 07, 2005: Message edited by: Jeff Langr ]
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, that was a sincerely twisted example. I'm not sure why procedural

print( a + b )

wouldn't be in the purest OO

( a + b ) print
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
Yes, that was a sincerely twisted example. I'm not sure why procedural

print( a + b )

wouldn't be in the purest OO

( a + b ) print



Or

stream print: (a + b)

 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stan James:

Yes, that was a sincerely twisted example. I'm not sure why procedural

print( a + b )

wouldn't be in the purest OO

( a + b ) print


I think it would. Of course, that involves even more code bloat as every single class must now have a print method.
 
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Obfuscated OOP anyone??

Actually this code looks like procedural code written in an OO language to me. It certainly shows how the author thinks. The equivalent of programs written when C++ first appeared - they were still procedural programs, just written in C++ syntax instead.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
Of course, that involves even more code bloat as every single class must now have a print method.



No, just those you care for having not the default implementation. It could be quite similar to Java's toString in this regard.

Which doesn't mean that I think it would be the best solution. But isn't that rather orthogonal to the subject of this thread?
 
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Steven Bell:

A frequent argument for OOP is it helps with code reusability, but one can reuse code without OOP�often by simply copying and pasting.



Reusability can be achieved by function.

When working with algabra, I often use use function-machine for reusability. Adding object oriented features to algabra only complicate things, no?
 
Steven Bell
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was just quoting the article. I found that rather funny.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerald Davis:
Reusability can be achieved by function.



Of course. You can even also achieve reusability in BASIC, Assembler and any other language.

It's just that with OO you have *additional* tools in your kit to help you achieve reusability at lower costs.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well said, Ilja. If you want to reuse something of mine you might implement a pattern, copy a design, copy a line of code, copy a method, copy a class, copy a package, copy a binary, call a binary running on my server, or many other things. Every one of them has more value (and potential risks) than sitting in a cleanroom writing every line from scratch. Making it easier is gravy.
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja Preuss:

No, just those you care for having not the default implementation. It could be quite similar to Java's toString in this regard.

Take that to its logical conclusion, and you have a dozen different types of print functions in the Object class (character based, binaries, going to printers or files, buffered or unbuffered, &c), as well as dozens of other output functions (show on screen, show as HTML, &c. &c.), and perhaps hundreds of other functions. The Object class becomes a heavily polluted global namespace.

I recognize you're not advocating this.

Which doesn't mean that I think it would be the best solution. But isn't that rather orthogonal to the subject of this thread?

I think it's germane: I think the often espoused philosophy of "make everything an object" does often lead to the kind of source code bloat that Mansfield complains of. What's needed is a balance between object oriented techniques and procedural techniques, so that one can use whatever is most appropriate for any given task.
[ February 10, 2005: Message edited by: Warren Dew ]
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


Of course. You can even also achieve reusability in BASIC, Assembler and any other language.

It's just that with OO you have *additional* tools in your kit to help you achieve reusability at lower costs.



Algebra can be functional but is it worth making it object oriented?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerald Davis:

Algebra can be functional but is it worth making it object oriented?



Not fully sure what you mean by algebra, but in Smalltalk basic arithmetic already is object oriented. That is not only very elegant, but also quite powerfull. For example, it includes support for arbitrary large numbers (as long as they fit into memory, of course) and lossless integer division.

That is, in the Smalltalk term "1/3", both 1 and 3 are objects (literals) of type SmallInt, which is a subclass of the abstract Number class. "/" is a message sent to "1" with "3" as its argument. "/" returns an object of type Fraction, which is again a subclass of Number. If you then multiply that Fraction object with 3, you get the SmallInt 1 again (in contrast to the double that is "nearly 1.0" you would get in Java).

As far as I know, you could even introduce your own Number implementation into the type system, if you needed some special case optimization, for example. And all that fully seamlessly, of course.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
I think the often espoused philosophy of "make everything an object" does often lead to the kind of source code bloat that Mansfield complains of.



I think it's creating the wrong objects and putting methods on the wrong objects that is causing the code bloat, not "making everything an object".

After all, in the statement

stream.print(a + b);

everything *could* be an object (in the right language).
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja Preuss:

After all, in the statement

stream.print(a + b);

everything *could* be an object (in the right language).


I think that a language in which all five symbols in that statement are objects will result in significant code bloat in actual use. Yet, that's what I've seen a lot of people try to achieve in their object oriented code.

And a language in which all nine tokens are objects ... I don't even want to think about it.
 
Ranch Hand
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From my personal experience, I focus on creating objects to achieve some functionality. Objects and applications exist only to provide functionality. Even in OO programming functionality comes first, objects are only created to implement some functionality.
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
[QB]

Not fully sure what you mean by algebra, but in Smalltalk basic arithmetic already is object oriented. That is not only very elegant, but also quite powerfull.
[QB]



I mean the pen and paper kind of algebra. Would it be an improvement to add object oriented features? Isn't object orientation so good that non programmers should use it to represent their notation, instead of using function michines.

Personally, I have not seen Smalltalk arithmetic, but I am sure it is non standerd and there would be a learning curve for maths specialists. Mixing object oriented features with domain spacific data only complicates thing, no?
 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Seriously, what is the point of discussing this? isn't it true that OO technologies are dominating market? Why VB went away? Why PB went away? even though they were considered "OO languages".
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerald Davis:
Personally, I have not seen Smalltalk arithmetic, but I am sure it is non standerd and there would be a learning curve for maths specialists. Mixing object oriented features with domain spacific data only complicates thing, no?



It is non-standard but simple. Everything in Smalltalk is a message send. Thus:

5 + 4

means send the binary message + to the integer object 5 with the parameter 4.

The implication is that precedence is from left to right by default.

5 + 4 * 3

returns the integer object 27, not 17. But you can override the precedence with parentheses.

One interesting thing in Smalltalk is that there are no integer overflows. SmallIntegers become (large/unbounded) Integers on their own.

I probably wouldn't choose Smalltalk for doing a math-intensive app. But I probably wouldn't choose Java either.

-j-
[ February 11, 2005: Message edited by: Jeff Langr ]
 
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeff Langr:
One interesting thing in Smalltalk is that there are no integer overflows. SmallIntegers become (large/unbounded) Integers on their own.



several languages have that property. Python may be the most commonly used such, assuming Perl doesn't have it also. (i've frankly forgotten most of the Perl i used to know.)

Smalltalk wasn't the only (or the first) language to manage exact fractional numbers, either - the Lisp dialects did, too. in fact, having what Lisp aficionados refer to as a "full numeric stack" is one of those languages' nicest features, one that few other languages currently in common use share.

now to heat up this flamewar a little more - what say i throw in some links to Paul Graham's ideas about OOP and Java? granted, it might be just stoking the fires, but you've got to agree Paul Graham is a better read than that "tablizer" person whose webpages started this thread.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
Ilja Preuss:

After all, in the statement

stream.print(a + b);

everything *could* be an object (in the right language).


I think that a language in which all five symbols in that statement are objects will result in significant code bloat in actual use.



I don't follow you. The above statement *is meant to show* actual use, so I don't understand what kind of "significant code bloat" you are speaking about.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic