The Object Oriented Hype 730
bedel231
sent us a fairly lengthy and detailed article discussing the hype
surrounding Object Oriented Programming and tries to claim that a lot of things taken for granted are mythical. Personally, I've never been a huge fan of OOP, so I tend to agree on a lot of these points. Regardless of your stance on the issue, it's worth a read.
Re:Myth... (Score:2)
The problem is that people tend to only code methods which are needed for their particular use of the object in question. And why shouldn't they? It makes for leaner code. It also makes for horrible reusability, because later when you try to the use the same object for a different application, you generally have to get under the hood and rip away at the guts to refashion it for YOUR use. This of course completely sidesteps the whole point of encapsulation and data hiding in the first place.
Re:The King of Argument By Authority (Addison) (Score:2)
Of course, you only gave two solid examples, admittedly from two of the best known and most respected men in the field, but still only two.
Even with a third, I'm sure Bryce wouldn't back down.
But compiler support helps a lot. (Score:2)
one can create objects in C by...
Yes. But by doing that you're sacrificing the compiler support.
And IMHO it's the wroing parts of OOP that get the hype. Encapsulation and strong type checking rate higher for me than code re-use or some aspects of inheritance (though polymorphism is right up there).
One big thing about languages like C++ is that they give you a way to express your intent regarding encapsulation and data hiding to the compiler and related tools, which then check them for you. (I'd say "enforce", but C++ also has ways to express your intent to deliberately violate the normal boundaries.)
It's really instructive to look at the "things to check for in a walkthrough" section of Miller's book on software quality. There are four pages of essentially one-liners describing the easy errors to make in languages like Fortran or Cobol. And with C++ they're vitrually all impossible to generate without producing, at a minimum, a compiler warning.
Now engaging write-only mode... (Score:2)
OOP invented PolyMorphism?! (Score:2)
...As if the world owes the concept of interface to OOP.
The concept of a wall socket is very old. It's so old, it's even present in UNIX. Look in your /dev/, and the interface that your devices are programmed to. The author of the web page is right; OOP is claiming a lot of inventions that are not it's own...
It's too bad. I wish more computer scientists look at computer science history, rather than the "Learn SQL, C++, and make a bunch of money" book shelf.
My .02 dollars (Score:2)
However, I don't think his real issue is with OOP, but with general programming practice in that sector. None of the developers with whom I worked took the time to actually design anything. They jumped in with their first idea and hammered at it until it "worked." They didn't care if there was a "better" design or a better way to do something, they just wanted it to work and for the customer (i.e. some other division of the company) to be happy with the software. If it came back for bug fixes later, oh well, that's what keeps us employed.
The real problem is not with OOP itself, but with the kinds of OOP tools (often linked to some RAD package) that are heavily used in this area and with the fact that so few of the programmers have the time to actual do design or code review. The managers were constantly telling us to review each other's code and to design everything, but no one ever did, and what passed for a group code review was a joke. No one actually looked at code. The lead programmer, often the only programmer, for the project stood up and gave a "best case" (i.e. outright lie) description of how the code works. Later, when some poor schmuck (i.e. you) has to maintain that very same code (which you were not involved in designing or coding in the first place) you find out just what a mess the code really is. The software more often than not did not even begin to approach the design discussed at the "code review."
Nah, the problem isn't with OOP, 'cause I have personally seen massive improvements in my coding since I've started using an OOP style with thorough documentation and formal notation. The problem is that in the very sector the author is complaining about, the vast majority of programmers are mediocre, and the managers (who don't do the work, but pick the tools and "methodology") are even worse. The problem is with buzzword programming where you pick tools because they are compliant with all the latest buzzwords, not because they are right for the job at hand, nor because your programmers know how to use them, which the majority don't.
Some folks need to go back to school!
Re:Now engaging write-only mode... (Score:2)
common misconception (Score:3)
one can create objects in C by creating a structure, then passing that structure to every method that performs on that structure. a common use could be something like this.
struct window_t win;
window_init(&win)
window_draw(&win);
window_destroy(&win);
it is also possible to perform polymorphism and inheritance with function pointers and other techniques.
-Jon
Re:Wrong (Score:2)
Simple. You can do abstraction in anything, even turing machines. Encapsulation is done in objects, otherwise you don't have encapsulation so much as namespaces. Not much encapsulation going on if you only have one capsule, neh?
--
Hammers, nails, screws... (Score:2)
I've always liked that saying (in various wordings):
"If you give someone a hammer, problems will all start to look like nails to him."
To really drive the point home, I like to add:
"...and what would he do if given a screw?"
There's also a response that I came up with once when a friend and I were talking about the coolness and power of some particularly cool and powerful Lisp-related thing (lest my previous post and/or my sig make me seem like just an old-fashioned C hacker):
"A sufficiently powerful hammer can turn any problem into a nail."
David Gould
Re:Tell us something we don't already know... (Score:2)
I gave up and decided to write in Python. It's still kinda complicated, but at least that's just because the code is doing something complicated.
Re:Wrong (Score:2)
Actually, it's worth noting that the original C++ implementation was a precompiler - it translated C++ to C. (I believe that this would be very difficult or impossible to do with today's C++.)
Can you do object-oriented stuff in C? Yes. It's often hideous, though. Motif was one such attempt. The horror...the horror....
The key attributes to a well-structured program (OO or not) are encapsulation and abstraction.
Can you get these in C? Yes! File scoping is the most underappreciated feature of C; it's often negelected because of poor revision control systems that end up encouraging a one function, one file paradigm. When you use it properly, though, you can put code and data members in a package with well-defined interfaces and the option of private data members. It rocks.
Can you screw things up by inappropriate use of OO strategies? Sure. Object-obfuscated designs with spaghetti inheritance are common, and are usually caused by becoming infatuated with inheritance and polymorphism at the expense of encapsulation and abstraction.
Tom Swiss | the infamous tms | http://www.infamous.net/
Re:"Object-oriented" languages (oops) (Score:2)
But it's not the global shift operator that's been overloaded, it's the shift operator associated with cout. Although it's not an oo feature as such, it is dependent on it. I.e. you're effectively doing cout.print("hello world").print(endl);
Rich
Re:"Object-oriented" languages (Score:2)
cout However, I wouldn't dream of claiming that the program is "object-oriented" simply because C++ is perceived to be an "object-oriented" language.
You know what? cout is an object oriented function! You can send it strings, characters, integers, and floating point variables without having to indicate to the complier what you are sending, as you do when using printf() in C. Try a better example. In fact, since C++ is a superset of C, I would submit that THIS is a truly non-OOPed C++ program:
int main() {
printf("%s\n","hello world!");
}
Now, THAT would compile with g++ and doesn't use anything OOP.
Re:common misconception (Score:2)
I did, just maybe not carefully enough; I guess you did say that, after all. You gave the classic "Draw() method for abstract class Shape with concrete subclasses Circle and Square" example, and claimed at the top that it was something that "With the structure+procedure approach, [...] would have to be [a switch statement]" Following that, the last sentence seemed to be claiming polymorphism as a virtue of OOP over C. Rereading it, though, I see that it sounds more like you are acknowledging that polymorphism can be done without explicit language support, which was also my point. If that's right, then sorry.
Mainly, I was looking for a good context in which to make the point of my last two paragraphs, namely that OOP is a bigger concept than a feature set of any language. In fact, I still have trouble with your initial argument that:
According to your definition there's no difference between procedural programming with good practices such as data encapsulation, and OOP. But there IS a difference... an object is self-contained.
We've already covered methods (explicit and otherwise), including polymorphism, and you specifically mention "good practices such as data encapsulation", so what else does "self-contained" mean? Will it still be anything that a good C programmer doesn't (or couldn't) already do anyway?
What I'm trying to say is that programming in an OO frame of mind does not necessarily require any particular language, language construct, or even programming technique (see my claim that even the version with the switch statement is in a sense OO).
David Gould
Perl is easy so lots of non-pro's use it (Score:2)
Re:Article Only Proves Low Education Level (Score:2)
I wouldn't put down those who write in Perl that much as being anti-OOP. There are many, many of us who write and like OOP in Perl (it's especially useful to read Damian Conway's "Object Oriented Perl" to see the beauty of Perl's OOP.)
OOP in Perl, actually, is much more fun than other languages because of it's flexibility. For instance, Class::MethodMaker is capable of creating accessor methods for various types of data members of objects at compile-time; this is a beautiful thing. Perl's flexibility has a whole lot of other things that allow fantastic OOP, and "Object Oriented Perl" expounds on much of this.
The Defense is Self Evident (Score:2)
The chief objective of computer programming is too create useful things. Elegance is tremendously valuable but secondary. NO OTHER interactive message board has come close to Slashdot in terms of useability, readability and even whiz-bang features.
Re:Article Only Proves Low Education Level (Score:2)
Didn't the author say that this is a question that needs study?
We have both enterprise-scale and small-business scale versions, but neither would survive long as a procedural app.
And your still a software house building apps for other businesses. The software you produce is your product, so you expect to extend and improve upon it. You don't expect to throw it away at the end of the quarter/project/fiscal year. It wouldn't last long as a procedural app, but the authors point was that most of the software he has been commissioned to produce doesn't last long...period.
Moreover, the enterprise "niche" is the greater part of the software market.
Your point being...?
There's no reason to object-orient the shitty little linux apps that you use, since they are usually 1-2 wannabe code monkeys writing bad C++.
OK. A personal attack. So if someone disagrees with you then their applications are shitty and they are code monkeys. Or is it that when someone buys the hype and uses the it-applies-to-everything sledge hammer to build a picture frame and ends up with a mess, then they are wannabe carpenters. Oh, and by the way, Chevy's suck.
Any multi-employee project requires the kind of abstraction that only OOP provides.
So you're saying that there are no large projects except those using OOP techniques?
I read as much of the article as I could stomach before his baseless graphs and lack of data made me stop, but I saw enough to know an Epsilon Minus Semi-Moron trying to sound academic.
You couldn't stomach what he had to say because it challenged your close minded view of the world. The author didn't present data, because (as he repeatedly pointed out) there is no data to present. OOP is hyped as the next big thing, but no one has studied the parameters of when, why, and where it is successful in any meaningful way. He stessed at the start of the article that he was presenting his view of the world and where he was oriented in order to have that view. His article was a data point and asked questions. Scientist and academics don't just present data, they also gather, analyze and question data and assumptions. Assholes and idiots, on the other hand, resort to name calling and flaming when their ideas of their own superiority is called into question.
It was a pathetic article, and anyone with a college degree and a smidgen of programming experience would tell you the same thing. It certainly provided a lot of laughs in my office.
There are a lot of people with college degrees and lots of programming experience who would say that it is a quite well thought out article. Many with the same credentials would say that the article is mediocre flaimbait. Either way, if this is what produces laughs in your office, then you need counseling.
Overall, the author tried to point out that no language is appropriate for all projects and tried to set parameters where one language/style of programming would be better than others. Of course, some people who only know OOP, believe that OOP solves everything and get upset when someone suggest differently.
Re:OOP invented PolyMorphism?! (Score:2)
I think you've misunderstood me, I most certainly was NOT claiming that OOP "invented" polymorphism, or anything of that sort. I was merely saying that polymorphism is one of the three main things that "OO" encompasses (and typically support at a language level). Nowhere does that even vaguely imply "invention". In fact I even rather explicitly stated that encapsulation is quite a natural concept in pretty much any paradigm - so how exactly did you arrive at the conclusion that I (or anyone else for that matter) was claiming that OOP *invented* those things? If you've seen that, its in your own mind, not in my post.
This Goes Back to one thing (Score:2)
Re:Some zealottery is good (Score:2)
But what evidence do you have that these concepts lead to good design
Holy cow, did you even read the part of my post you are quoting? I said it DOESNT lead to good design. Good design has nothing to do with the paradigm you're using. You must have been in a seperate universe or something when you read my post, you've missed the whole point.
Re:GUI's vs GUIs (Score:2)
http://www.angryflower.com/bobsqu.gif [angryflower.com]
Apostrophes are certainly NOT used for plaurals in any way, shape or form! I think I know who needs a slap in the face...
Orbix? Yuck! (Score:2)
It's 2 years since I used it. Back then it felt like a bad port from UNIX to Win32. We couldn't have any COM DLLs talking to our CORBA services. Why? Orbix spawned some threads and provided no way of deleting them. This caused crashes when the COM DLL unloaded, or it caused a crash on exit as the process shut down. Unusable.
Re:Wrong (Score:2)
Looking through the sources of GNOME and GTK is quite a trip--it *seems* well-organized, and probably is. But the language idioms used are frightening--it's C, and legal C at that, but at what cost? No one offers training in this dialect--universities use object-friendly languages when teaching object-oriented design, and businesses use object-friendly languages when they need object-oriented design.
The clearest book on C++ I've read comes in near 1000 pages. If I want to contribute to most GNU projects, I have to generate the knowledge of their equally complicated pidgin OOP-C for myself by staring at reams of barely-commented source code. If written in C++, the code would be identically fast and have 25% the footprint, and probably fewer bugs too. But RMS says no, so they don't do it that way.
Re:OOP...in BASIC? (Score:2)
Now, I'll be the first to admit, their idea of "objects" strains the definition a bit, but with a very loose interpretation of what OOP is, this fits the bill.
Re:more empty claims (Score:2)
I would claim that any well-designed procedural app looks a hell of a lot like an OO app. Relational and object are technologies that can go together, they are not mutually exclusive concepts.
I see nothing inherant in OO that really improves maintenance in the business domain. Inheritance does not model business things well, and OO's version of HAS-A is messier than procedural IMO because you have to have an object reference attached to lots of stuff and find a class to stick every method into, even if it should be self-standing.
Inheritance != OO. Inheritance is a necessary property of an OO language, but that does not mean one should use inheritance every chance you get. Properly used inheritance is like a good spice--use it sparingly. A sign of a bad OO system is one with deep and/or complex inheritance hierarchies.
The advantage OO has is that it is a discipline that describes how you write well-designed components. Procedural is not analagous to OO, as it does not prescribe in any way how you properly design your code.
Re:Reply to your claims (Score:2)
Modules are available in some procedural languages also. (Don't bring up state. It was already mentioned.)
I was specifically referring to the benefits of C++ over C, and in the real world many programmers don't even have the discipline to structure C into module definition (.h) and implementation (.c) files, or even to use #ifnedf/#define protected headers. I programmed in Modula-2 for many years, and it's a great language, but hardly an option for most projects today, and certainly lookigng rather dated in terms of features.
[quote] It encourages opaque data interfaces (method access vs public access) which results in less bugs [end quote]
Real-world business example?
How can you feel qualified to write an opinion piece on design technique (OOP) if you can't understand this without an example???
Let me spell it out for you:
If you make a C++ data structure member private, and *only* accessible via methods, then you remove the possibility of people using your class accessing or modifying the data structure in incorrect ways. One source of bugs made IMPOSSIBLE.
BTW, who said anything about business programming?
If anything, this tends to create set/get bloat--One of the silliest structures that is just crying out for some sort of cleaner factoring. Also, they can often be replaced by good data dictionaries.
Usually the data structures involved would be something more complicated than a variable that can be "set or get"!!!
With your comment on data dictionaries, you again seem to want to limit the discussion to business, and specifically database related, programming! Odd.
[quote] It makes use of self-initialization/cleanup (constructors/deconstructirs) that avoid a whole slew of programmer errors. [end quote]
I just got chewed out by readers who claimed that defending my garbage-collection myth was a strawman because nobody believed except a few dummies.
I'm talking about C++ constructors and destructors period. Who said anything about garbage collection??
In short, you are comparing C to C++. C is NOT the pennacle of procedural/relational programming.
Is this meant to be a practical discussion or not. In the real world there are very few widely used languages. Outside of the modern scripting languages like Perl/Python/etc, and leaving aside specialty anguages like VB, you've basically got C, C++, FORTRAN, COBOL, Java, and Ada if you work in the defense industry. Where's your pennacle [sic] of procedural languages? Ada?
[quote] The self-containedness of objects does make code reuse simpler and less bug prone. [not quote]
Specific example?
Huh? Are you challenging that statement???
Perhaps you think it's easier to resuse code when there's MORE to think about and get right, rather then LESS?
Again, these all sound great on paper, but when specifics are looked at by the non-indocrinated, the ugly grey of OO thinking starts to ooze out.
I'm neither talking about on paper, nor am OO "indoctrinated". I've been programming for over 20 years in languages including 6502/Z80/68000/16032/x86 assembler, BASIC, FORTRAN, COBOL, Algol-W, LISP, Pascal, Modula-2, C and C++. IMO C++ is simply the best general purpose language available today for utilizing the sound prgramming techniques I've learned over the years, and OO is to a large degree just a modern name for design techniques that have been around for years, but are now better supported.
Re:word games (Score:3)
Just because many people don't understand the definition does not mean that the definition is vague or watered-down.
Anything that is "not at the right spot when you need it" can be blamed on "lack of encapsulation".
I would more likely blame lack of coherent design. But lack of encapsulation can result from the programmer hacking his way around the encapsulation to solve the problem.
Note that many of the goals of OO can be achieved in ways that are not necessarily OOP.
Agreed.
--
Re:common misconception (Score:3)
You signed an NDA on that design. Expect a call from our lawyers.
--
Re:Wrong (Score:2)
Pray tell, how do instantiate a file at runtime?
--
Re:My view (Score:2)
I don't know why, but I just can't stop chuckling after reading that
--
Re:bad code == secret language == job security (Score:2)
So, maybe I exaggerated with the "massive improvements" bit, but I'll tell you that it's certainly more fun to code using some kind of plan/design. In my case, usually OO, and usually in C, C++ or Perl. Nothing better than reuseable objects if you ask me.
At my previous place of employment, there was an attempt made to do that very thing: build a reuseable framework of objects for the business software. There were problems galore with making this work because one of those drag and click types of commercial "programming" tools was chosen, where you create graphical objects on screen and then add code inside the objects, code that's tied to that graphical representation and to that object. In other words, the code was not factored at all, and if you needed a different widget, or even no widget, that implemented the same business rules in code, then you had to rewrite the functionality from scratch. Very poor planning, and just shows that the problems with OO are not really problems with OO but with OO that is misapplied by developers who don't really understand the paradigm.
Re:OO is all about components??? (Score:2)
Sparingly is not the same as not at all.
What is left? Encapsulation? That is a loaded issue because what aspect to "encapsulate" by is not cut and dry.
Encapsulation, polymorphism, and abstraction. And encapsulation is the big piece. In OO parlance, it means to capture the data behind a concept along with its behaviors--and not expose that behavior and data willy-nilly to the public.
So OO is all about component design?
Not entirely, but it is the most critical element. An OO language is simply a language that maps well to OO component designs.
But there is also OO analysis.
That does not sound like a majority OO fan stance to me.It is probably not what you hear from the inexperienced Java and C++ programmers who think they know OO because they are using an OO language. However, most OO experts will tell you the language and the technology only have a secondary importance to the OO-ness of a system. It is the design.
Besides, the making of components themselves are not what most custom application programmers do. Does that mean that OO is nearly useless for them?
What are you talking about? Custom does not imply not componentized. A custom application can be built from existing components. Similarly, just because you are writing something for the first time does not mean it is not a component.
Procedural tends to emphasize grouping (encapsulation) by actions, while OO tends to emphasize grouping by nouns. This is perhaps an over-generalization, but seems to hold true time after time.
This is a crude description that serves only to help someone who has no understanding at all of the difference between OO and procedural so they can get an initial grasp of the concept. OO is about modeling a system, not programming. It looks at the processes to be modeled, aka use cases. Note, OO starts with actions! The system then looks at the things involved in these actions and the ways in which they interact. Then classes are built to model the things and their interactions. OO is things and their actions, procedural is nothing more than actions. And that is why procedural applications are poor models of the processes they are supposed to be modeling.
Re:common misconception (Score:2)
A good solution in C isn't quite as simple as you described. Specifically, your circle is described by parameters top, left, bottom, & right. Not only is that an inefficient way to describe a circle, it is ambiguous for other simple shapes (e.g., two different ellipses can have those 4 parmeters be identical). So, to do it "right" in C, you'd have to do something like having your shape structure hold a pointer to another structure that holds the shape parameters.
First, let me mention that I had originally included a line "//..." after the "members" and "methods" declaration lines in the struct, to indicate that more would go there, but Taco's so-called "lameness filter" once again demonstrated its own lameness by tagging them as "junk characters", so I had to take them out to post it.
I don't disagree with you much, but my example still deserves some defense. It may not be a good (efficient or even sufficient) way to describe geometric shapes for mathematical purposes, but it is good for objects that correspond directly to stuff that is to be drawn to some output device. Most 2D graphic toolkits I've seen have a DrawOval() function with exactly the same interface as DrawRectangle(), i.e., they take a Rectangle (struct or individual coordinates), and disambiguate the ellipse by using the one with vertical and horizontal radii. Even if the rectangle coordinates have nothing to do with the specific shape, they are needed because the code that manages the shapes together generically will need to know each one's bounding rectangle, so this information is universal to all shapes. In OOP terms, it would be in the abstract base class; in non-OOP syntax, it would be in the struct as I have it, along with (as you say) a pointer to another struct with any additional (you didn't say that) shape-specific information, which would have gone in the place of my lamented "//...".
Note the phrases "In OOP terms" and "in non-OOP syntax" -- this gets back to my main point about OOP as a way of coding vs. OOP as a way of thinking. It's not just (as we all seem to agree) that you can do OOP without the syntax by using some (admittedly, increasingly awkward) techniques. I'm also claiming that there's not (necessarily) anything special about "OOPy" code at any level. In some sense at least (I just seem to keep adding that disclaimer everywhere) OOP is in how you think about it, no matter how you implement it, or even whether or nor you implement equivalent techniques at all. Even if you don't use the tricks we have been discussing with structs and function pointers as substitutes for OOP syntax, your code could still be called "object-oriented" as long as it is structured around entities or things with behaviors and interactions that model stuff, which will probably happen to some degree whether you think about it in those terms or not.
David Gould
Re:The macho paradigm? (Score:2)
Comparing OO Components to procedures is just plain silly. They are different concepts. Read Szyperski's book on components (and yes, non OO components do exist).
"The real world does not give a rats behind about fat-type trees. It will change any way it feels like."
The real world is also full of fools who make the same mistakes over and over because they think they are experts while in fact they are not.
"A graph-oriented approach like relational modeling and HAS-A relationships model this aspect of the real world better."
You should take a look at adaptive programming and aspect oriented programming. (use google to find the relevant material). Both approaches extend the OO paradigm to support what you want.
Re:Orthogonality Problems (Score:2)
No, you appear not to understand OO encapsulation at all. The aspects you speak of are nothing more than views of the object, and it has nothing to do with encapsulation.
OO encapsulation actually works very well in the real world. Consider, for example, the use of a Date object instead of a char array or even a long. With the Date object, you have one place to fix your Y2K problem if you made the mistake of storing the date internally in the Date object as a char array with the year in 2 digits. If you make the same mistake in the procedural world, you end up with a big ass bug that costs a hell of a lot of money to fix.
Look at something like the OO Visitor Pattern. That is the mess created by increasing the aspects by *one* dimension. Add another, and kapoof!
If you think it is a mess, then you do not understand the pattern. The Visitor Pattern helps eliminate the mess the same code would otherwise have in either OO or procedural realms. And, the Visitor Pattern is also overused in places where it is not appropriate.
Close enough. Languages should only support fairly common things, not blue-moon things. Otherwise, it ends up being and electronic packrat or offer arbitrary features for bored programmers to futz around with (and they *do*).
Ugh, it is not "close enough". It is nowhere near close enough. Most classes in an OO system will inherit from something else. Sparingly means that your inheritance trees are simple and shallow.
Yeah, everybody bashes everybody else's modeling techniques, even WITHIN the OO community. This is what happens when there are no metrics. Metrics are the cops of ideas.
First, this paragraph changes the argument. Your original point was that a lot of OO "fans" seem ignorant that OO is about design, not coding. Now you say that the problem is everyone is bashing everyone else's modeling techniques and there are no metrics. A different argument.
On the new argument, however, you are still wrong. There are formal processes, with the Unified Process being the most widely accepted process. And as with anything, there are expert OO modelers and there are wannabes. Expert OO modelers are getting the job done.
I hope you are not one of those who try to generitize everything.
Nothing I said suggested I do. So the rest of the paragraph that follows is meaningless since it is based on that assumption. However, your claim that you can never have true genericity is absurd as trying to make everything generic. What do you call the Date class in Java?
On use cases, This is not really OO, per se.
Uh, yes it is. It is the starting point of OO software engineering. Non-OO processes do not model things in this manner. They start with workflows and decision trees, which are very, very, very different from use cases and object interactions.
The rest of your post is on how you think your tables and procedures are the best models for a reporting system. First of all, your dismissal of OO for this problem shows a poor understanding of how the modeling should be done. ER data models are nothing more than collections of DATA and ways of relating the DATA. While the data is data about things in the real world, the table structure is only indirectly and poorly a representation of the thing being modeled. The result is that systems relying on the relational database as a model of the business processes end up being difficult to impossible to maintain over the long haul.
Re:OOP *is* really the next level (Score:2)
However, here's a quick example where OO excels. I was in the game industry for many years. Virtually all games involve a bunch of "things" moving around on the screen, anything from spaceships and laser beams to puzzle pieces falling from the sky.
For years I struggled trying to reconcile the fact that all of these "things" are very similar in many fundamental ways. They all move around and bump into other things. They all need to be saved to disk and loaded again at savegame time. They may need to blow up or otherwise be destroyed when certain game events happen. And of course, they need to display themselves on the screen somehow. Yet they are all very different - the logic that controls, say, an homing missle is quite different from the logic that controls the player character, for example.
During this time I wrote hacks involving void points, casting, functions with huge "switch" statements at the top to try to figure out what something was, and other roundabout ways to handle all the similar functionality of these things in one place, yet still allow for all the special code that goes with each type of thing.
OO solved all of that nastiness for me. It pretty much works the same in the end, but it's much easier to code, and *vastly* more maintainable. I can now make a base class entity, and derive all my specific types of things from them. I have virtual functions for Move(), Collide(), AI(), Update(), Draw(), which have defaults, but I fill them in with special code for each type of thing, and I never have to duplicate my basic motion/collision/whatever code, nor are there any messy hacks to be able to put all these types of things into one giant list of entities, but still have each thing "know" what it is and how to behave.
It's more complicated than this, but that's the gist of it. Every game company I've worked at has used this scheme almost exactly (although the terminology may differ) because it works so well.
Re:God's Hierarchies (Score:2)
Re:Another reason ... (Score:2)
FunOne
Evolving interfaces (Score:2)
trying to do everything with inheritance is bad (every non-novice OO
programmer agrees), and secondly that you don't support for classes
and objects to get the benefits of object orientation (but you need
first-class functions and dynamic/existential/abstract types, obvious
to the LISP world for over twenty years).
Object orientation makes it easier to manage changing interfaces.
Support for object orientation makes it easier to achieve this in
programming practice. The author seems so upset about bad designs he
has encountered caused by an inflexible, deep inheretiance that he
seems blind to the fact that OO support can facilitate good design.
Re:People think in objects (Score:2)
One of the basic assumptions is that the human brain is built to think about the world in terms of things that have properties and behaviour. We can think in terms of procedures and execution flow as well, but we're not nearly as good at it.
The problem is, humans tend to think in terms of something acting on something else. With the data and methods mixed together, it feels like building a house by 'asking' the nails to hammer themselves rather than 'asking' the hammer to act on that nail.
The real benefits (Score:4)
Myth: OOP is a proven general-purpose technique
Myth: OOP models the real world better
Myth: OOP makes programming more visual
Myth: OOP makes programming easier and faster
Myth: OOP eliminates the complexity of "case" or "switch" statements
Myth: Inheritance increases reuse
Myth: Most things fit nicely into hierarchical taxonomies
Myth: Self-handling nouns are more important than self-handling verbs
Myth: Only OOP has automatic garbage collection
Myth: Components can only be built with OOP
Myth: Only OO databases can store large, multimedia data
Myth: OODBMS are overall faster than RDBMS
Myth: C is the best procedural can get
Myth: Implementation changes significantly more often than interfaces
Myth: Procedural/Relational ties field types and sizes to the code more
Myth: Procedural/Relational programs cannot "factor" as well
Classic OOP features such as inheritence may generally be over-hyped, but specific cases such as polymorphism are very useful (even if there are ways of doing the same thing in languages such as C that were not designed for OOP).
Some of the major benefit of OOP, and specifically C++'s objects, are:
o It is a clean module packaging mechanism that encourages cleaner interfaces between modules
o It encourages opaque data interfaces (method access vs public access) which results in less bugs
o It makes use of self-initialization/cleanup (constructors/deconstructirs) that avoid a whole slew of programmer errors.
o The self-containedness of objects does make code reuse simpler and less bug prone.
etc, etc.
The guy who wrote the article (and the esteemed Mr. Taco) appear not to have much hands on experience writing OO code.
Re:reusability... (Score:2)
I don't know very much about OO -- I learned about it at University (in Eiffel) but it never 'clicked' and I always found OO design to be something of a strain. I only mention this to demonstrate my bias
However, you seem to be implying that code re-use is something you only get from OO, and that just doesn't make sense to me. I really only code in C and Perl these days, and I reuse code all the time.
--
Table-Oriented + OOP (Score:2)
And I've seen at least one OOP project go down the tubes because the designers, among the smartest people I've ever met, treated data persistence as just another implementation detail--they had been seduced by the model of a computer that never fails and has unlimited memory.
But one of the most successful projects I've seen is one where an object-oriented framework provided a transportation and communications infrastructure on which table-oriented applications could be developed. OOP gave us just right level of hierarchical abstraction to make platform-specific issues irrelevant to higher layers; at those higher-layers, the mind-boggling flexibility of table-driven rule sets provided a potent way to model business processes without trying to put everything in exactly one box.
I do believe we are heading for a convergence of sorts. The tables in question are going to be XML, with Java (or pick another OO language) providing the framework in which (and with which) to parse it.
--
This is not just OOP versus Procedural (Score:2)
Check out abstract, typed functional programming in a language like SML, O'Caml, or Haskell (I find it's much easier to write abstract modules in these languages than it is to do so in an OOP language). Check out logic programming in a language like Mercury or lambda-prolog. Don't forget the zillions of other genres and subgenres.
C'mon, slashdotters, it's your responsibility to ignore the marketing hype and use technology because it's superior. Do your shopping before you fall for something because everyone uses it (procedural) or because it's buzzword-compliant (OOP).
there is something to be learned! (Score:2)
It's a good analysis (Score:2)
I use OOP and procedural programming because they each have benefits. It enables me to clearly envision the flow of code and make everything modular. It also enables me to manage multiple instances of the same type of object easier. However, it's possible to implement the same functionality in procedural form. And somebody familiar with coding everything as procedures can visualize the code just as easily. If you have used procedural all your life and are familiar with it, then you can perform the same tasks as somebody that is experienced in OOP.
Using procedures, you may have a separate source file for procs related to working with strings. You could also use OOP to declare a string object, and just put all the functions within the object. Note: The above is just an example, don't EVER waste time with string objects unless you are forced to.
It's really more of a personal preference than anything else. Synonymous with your wallpaper. In the end, all that really matters is whether or not the software performs its intended function.
Re:common misconception (Score:2)
Since g++ (the GNU C++ compiler) is written in C, C and C++ are equivalent. In fact, all programming languages are equivalent. You could write OO code in a big pile of NAND gates if you really put your mind to it... or on a Turing machine... or on a Neural Net... etc. Basic language theory, that.
Just because a language doesn't provide the syntactic niceties of (say) Eiffel, doesn't mean you can't create objects with methods and inheritance, and ask them to run said methods.
--
Myth... (Score:4)
This is the most stingingly correct point, in my opinion. In fact, in my experience, they change equally often at best. And in cases where code is actually meant to be reused - something which, by the way, some of my smartest friends have told me, after no small amount of experience over the years, never actually happens - its the interface that often proves more likely to need modification...
Re:Poor criticism (Score:2)
I just heard someone say that they found an old procedural program of theirs that used too many global variables and too many parameters. Rather than blame his bad programming or lack of knowledge about procedural/relational organization techniques, he blamed the paradigm and used it as a sorry excuse to proceed with OOP.
Ironic given his very long rant essentially pointed at bad OOP implementations rather than OOP as a paradigm!
Of course, I run Cetus Links [cetus-links.org] so I may be biased...
--
core reuse and objects (Score:2)
Personally I think OOP is okay in some cases© Take for instance Tcl/Tk© Tk is probably the best GUI programming language that I have ever used© Unfortunately that is about all it is good for© Yes you can do more with it, but I think the GUI is is probably the best© Guess what it is done with objects as well© The button, the text the lable the entry, etc© Tk is also not to heavy as far as overhead either© Some may say that java is better, but I have actually tested a simple GUI text editor and the java editor was slower to start and slightyl slower than Tk© I have also used powerbuilder© Now there is a nice OOP language© To bad it is so slow and flakey©
I have also tried C/C++ and the problem they both have it memory management© And lets face it trying to figure out do I need to destroy or free this can be a real pain in the butt©
Personally I'd like to see a language that has syntax like perl, but is compiled and effecient like C© Maybe C with garbage collection© Instead of me having to malloc and free, I'd just declair char * item;, and then maybe item = "string"; Then when I am done with that string I'd forget about it© Sort of like Java, but a language that does not require you to do everything with objects like perl© More like a JavaScript / perl / C / Java cross© Powerscript ¥Powerbuilder is close, but is not a general programming language, it is a propritary language©
Oh and if you look at KDE and GNOME projects, both have major code reuse and one is OOP and the other is not ¥not really, and they are both awesome works of coding©
I don't want a lot, I just want it all!
Flame away, I have a hose!
Re:Another reason ... (Score:2)
On the other hand a compiler could spend time optimizing this stuff more (maybe more inlining of those tiny calls at least).
The one thing that is a compiler issue in my posting is the poor use of the call/return paradigm (for example using a jsr to make a call, but not ret to get back means the architecture can't do a hidden [branch target predictor] stack cache to keep the pipe moving - many modern cpus, even x86s do this)
Re:I tend to agree with the author.. (Score:3)
Structured programming a fad? OOP a fad? A rather long-lived fad then! Software developers have been using structured programming techniques and OO design for years, and will continue to do so.
Personally, I believe you should program using the style you're most comfortable and familiar with. If you're trying to fit a mold it will slow you down.
That's fine if you're working on a small project with maybe one developer. But if you had 30+ developers using their own techniques and styles on a large project (like the >1MLOC project I've been working on for the last 5 years) you'll end up with an unmaintainable mess. If everyone conforms to a standard methodology and style then at least you can maintain each other's code.
This is one of the differences between software ENGINEERING and code that's been congealed instead of designed. Software engineering should result in a robust and maintainable system. Letting every programmer go off and do their own thing as you advocate leads to the truth in the phrase "If builders built buildings the way programmers write programs, the first woodpecker that came along would destroy civilization!" It sounds nice to let the programmer go off and just write in their own style using their own unique design techniques. But it's terribly naive and unrealistic in the real world.
Re:My view (Score:2)
snip
And you know what? I've never understood OOP. I just don't "get it." Sure, I understand the theory, but when it comes to real work, I've never understood it.
It's like if everyone started calling the TV a "forbick". Doesn't make any sense does it? I mean, it's a TV. Why call it a forbick?
To use a language (any language) you have to grok it, and think in that language or - in the case of OO - in that kind of style. Your example of calling a TV a "forbick" is kind of right on - the French, for example, call cheese "fromage".
You'll never be a good Francophone if you have to think in English, then translate to French, and say it. You have to actually think in French. Same with computer languages. When I first learned C, I was thinking in BASIC and translating. It didn't really work very well. (BBC BASIC doesn't have pointers for one). It was not until I grokked C and started thinking in C that I got any good at the language. Although it seems natural to think in C then code in C++ because the languages are so similar, unfortunately it won't work out very well. You have to think "object oriented" instead of thinking in non-OO and translating. Once you get to that stage, you'll truly grok OO and its usefulness.
I'm currently learning Perl. I'm trying to start off thinking in Perl rather than thinking in C++ and translating. So far, it's working OK, but I'm still doing things the C way that would be better done the Perl way, so I guess I'm not truly thinking in Perl yet!
Re:My view (Score:2)
Re:common misconception (Score:2)
There are problems where OOP is good, and problems where it's not such a good idea. If you insist on using one or the other, pick those problems that it's suited for. I admit that I have some real problems with object-oriented programming's approach to things, but I don't want to convince people to give it up. Just don't make me do it. (That's the main reason why I chose not to do CS in school.)
OOA article (Score:2)
Much of this article seems to be OOA, Out Of Ass. The author states many figures such as designing takes 3 times as long with no backup. There are some points but most of the apply to missused OOA&D.
Object reuse only coming after years. Well, I work for a company that is a big user of object technologies. We have our own data access, mapping, and server objects that are our bread and butter, we can go in and have an application up in little time because we don't have to write most of the functionality, just abstract the business logic.
Buy in. That is true, if not everyone buys in the programmers will be pulling their hair out, however this is true in the development contract of many methodology.
Not everything is abstractable/in a hiearchy, true but I find in most of the work I do, it is. There are cases where some of what needs to be done doesn't make pretty objects, but that is the exception
A longer viewpoint... (Score:2)
'Bout 7 years ago, I took some coursework in OOPs and GUI (sounds like someone dropping an egg, to me), and what I saw then was this:
1) OOD looked real good...BUT the closer you got
to actual coding, the fuzzier it got (as
opposed, for example, to flow charts), and
2) what OOP appears to be doing is enforcing by
compliler all the good coding practices
that they've been trying to teach for
25 years (y'all use goto's in C,
frequently? how bout type checking?).
What I've seen since then is that it *may* be possible to write good, tight code in an OO language (though I found the person who worked on chips cmts, above, fascinating), the overwhelming majority of coders write *lousy*, bloated code - you want a clipping of Gojiro's (Godzilla, to those who don't know) toenail, and you get the big guy, himself, with a window frame around his toenail. Explain Lose98, or LoseMe, or M$ Office....
Reusability - isn't that where knowledgable management assigns the position of librarian to someone (*sigh*, probably the configuration manager), and they make sure that programmers use existing subroutines? Oh, right, sorry 'bout that oxymoron about "knowledgable managers".
Thank you, some of us would rather master our discipline (check the meaning in the dictionary that doesn't refer to whips), and write good, tight, fast code...that can be maintained by someone else, when we've moved on.
mark
OOP isn't magic, but it's still great (Score:2)
Personally I write OOP only very rarely, but that's partly to do with the nature of my work which is more small program oriented than large system oriented. However, I do find OOP to be significantly useful in lots of occasions. One way that Objects are particularly useful is in extending programming languages. The old style of libraries is somewhat cumbersome and leads to unnecessarily bloated code that is more difficult to read (and to understand easily), whereas extension via object makes immenently more sense and keeps your code (which may or may not be Object Oriented) a lot tighter. Perl demonstrates this excellently since most Perl programs are not Object Oriented, but almost all the "extensions" to Perl that are being written (and being used) these days are Object Oriented.
And in some ways OOP is still playing catchup with older programming styles, it's a lot easier to change languages than it is to change to a whole new philosophy of programming and I think that has shown. OOP is not a fad, it's most definitely here to stay and in fact I think it will grow as more and more languages (other than C++ and Java) take on Object Oriented design and more and more programmers learn when and when not to use OOP.
Article Only Proves Low Education Level (Score:5)
I work in a software company, and our product takes up no less than 300 MB of code. Even in the most well-organized non-OOP code, our software would be impossible to debug or even build, because we would need to go through hundreds of lines of code. In addition, reusability would be hurt, since even though the functions would be there, minor changes in the arguments might make the entire function worthless.
The author's example using People and Taxes is particularly striking. He suggests that an object oriented approach would create a person object and a tax object, set their attributes, and run the T.CalcTax method on Person P, while a procedural approach would just feed the relevant parameters to a function. I wonder if the author has ever actually filled out the 1040 Personal Income Tax Return Form [fedworld.gov]. The easy version has 70 entries, and while some are calculations, others are references to other, much bigger, forms! Keeping track of all these variables without some structure to hold them all is just stupid. Object orientation is necessary when code hits a level of complexity where several people, or several hundred, are simultaneously working on a project. The "black box" approach allows for greater flexibility and optimization, since a code change will be transparent to the objects around it.
Another thing to consider, although I know CmdrTaco would berate me for even mentioning it, is the expansion of OOP provided by Java. The Interface in Java allows you to specify several functions, abstractly, that are required for a class to implement the Interface. The implementation of these functions is class-specific: for example, all clothes implement the Wearable interface, but you would not want underwear and shoes to have the same implementation of Wear(). However, in Java, you may specify a function to take a Wearable object, and not need to specify any further. This abstraction level is why OOP does, in fact, better model the real world.
In conclusion, the rantings of a PASCAL junkie should not constitute a Slashdot article. Anyone who has coded in procedural and OO languages should see the extreme idiocy of the article within milliseconds. On the other hand, Perl powers Slashdot, so I guess this is the place for the procedural approach to have its message heard. In fact, Slashdot totally vindicates the article: its non-OOP approach is fast, effective, efficient, and easy-to-understand. Highly scalable and expandable as well. I especially like Slash.pm (aka THE BEAST) and the my_conf{shit} variable. I'm sure the non-OOP approach will really take off once everyone switches over from C++/Java to Perl.
OO is dead as a silver bullet, alive otherwise. (Score:2)
Ultimately, multi-paradigm languages that can absorb new techniques as they mature, like C++ and perl, will be the winners. I have yet to see a mono-paradigm language have sustained appeal over a five to seven year period.
Spaghetti code, anyone? (Score:2)
Unfortunately, the thesis was quickly replaced with some teenage-esque rants that have been noted already.
What seems to have been overlooked is the advantage of OO: code maintainence. In entreprise environments, a great deal of time is spent on project maintenance. Anyone familiar with procedural programming can testify that scanning lines of undocumented and tightly written code can be a nightmare. The old ideals of syntatic efficiency at the expense of readability, while fun and good in the hacker world, don't fit into the corporate world.
OO attempts to solve this problem by introducing a methodology that makes it easier for programmers to make their code maintainable.
This is analogous to the manager that keeps all his notes in his head versus the manager that documents his job and his notes. Both can probably do a great job, but when they move on, which one do you want to replace? I'll take the latter.
All the arguments about procedural programming being faster and easier than OO are moot: it's the nature of the beast. But OO is definitely a great tool for facilitating ease of code maintainence and leveraging past effort.
I can't believe the guy that wrote that post has had any career of significant length.
Re:I tend to agree with the author.. (Score:2)
I've seen any number of C++ books which are effectively C books, using cout instead of printf, with an object orientation chapter tagged on as an afterthought.
I'll bet a lot of Windows programs use OO to work with the GUI (because MFC makes them) but have an underlying program structure that's procedural to the core.
I've no doubt that OO is heavily used, but you can't get comparisoms just by counting how many programs were built with a C++ compiler.
--
Comment removed (Score:5)
Re:Tell us something we don't already know... (Score:2)
There's no magic bullet... (Score:3)
Thing is, if you can't do design in procedural code, OO's not going to buy you anything. Projets that buy into the aforementioned hype will fail. A company throwing OO at a projet without investing in training of it programmers will see the project fail. There are some simple OO mistakes that you see new programmers or procedural programmers who've never done OO before. Deriving everything from everything else. Using inheritance for everything. Habits that it's hard to break them of because nobody realizes that they're bad habits.
Do a bit of research though, and you can find ways to be very productive using OO. If the designs are good, it does actually get easier. Buy "Design Patterns" and poke around in the various OO language netnews archives for little nuggets of wisdom and you will find your object designs improving immensely. Read about STL and use well designed toolkits like gtkmm and you'll start to realize benefits from using Object Oriented programming.
Wrong (Score:4)
Of course it "supports" them. It's just not as easy as it is in other languages. As has been pointed out before, creative use of function pointers in C can be used to implement polymorphism and "dynamic binding."
Think about it a minute. What does a C++ compiler do? It translates the (high-level) C++ code to (low-level) assembly code. Are you somehow suggesting that there is no way that the generated assembly code can implement inheritance and polymorphism because no assembly language "supports any of those?" If so, how is it that C++ programs are able to compile, link, and execute? The original C++ compiler, cfront, generated C code as output from the input C++ code. Surely the output C code was no less "object-oriented" than the C++ code it was generated from.
You can write object-oriented code in nearly any language. The difference is how much language-level support for OO is provided. Just because you can't write "virual void myFunc()" in C doesn't mean you can't generate the same behavior.
Wow! A Troll on the frontpage! (Score:2)
OOP is communistic?
No references? (Sorry, we lost them...)
A giant stinking POOP image header?
perhaps this should be under the humor category...
People and Taxes (Score:2)
Nope, I'd just add a calcTax function to the Person class I already had. Maybe this explains why my objects seem to have a lot of functions....
:-)
To take the Tax and People example you have given, you have overlooked the fact that an object oriented approach allows inheritance and lots of other stuff. For example, if there was more than one type of tax T on a person P, one could still call a generic function T.calcTax(P) for both InheritanceTax and IncomeTax classes which inherited from the basic Tax class.
Object Orientation is not an answer to Life, The Universe and Everything. And you often find that one persons idea of an object oriented approach to a problem is totally different from another persons idea. But having said that, I find that it is easier to work out what someone has done if they have used an object oriented approach than if they haven't. For one thing, most people implement all functions of each class in a single file named after a class, something you're never quite sure of with a parameter approach.
Object orientation simplifies maintainability, by encouraging people to write in a style which may be easily understood, something many other methodologies have singularly failed to address.
Re:Examples? (Score:3)
If implemented with discipline and knowledge, an OO project is better maintained than a procedural one. However, I would take a disciplined procedural project over a messy OO project. The overall guiding point is rigorous software engineering, and OO provides some language level discipline, while procedural programming provides nothing at the language level. If a good process is followed, though, language level support is just convenient fluff.
Russell
NO silver bullet but C++ multiparadigm is usefull! (Score:2)
What is Object-Oriented Programming? [att.com] (Link to papers, since I can't find the
Multiparadigm Design and Implementation in C++ [computer.org]
Design and Evolution of C++ [att.com]
Now I'm not saying C++ is the end-all and be-all, but every language was designed to solve a certain problem. Use the right tool for the right job! If C++ lets you solve your problems quickly and efficeintly, then use it. If not, then use what works.
Re:reusability... (Score:2)
You obviously have a situation that calls out for OO design and programming. Now explain how that means that absolutely everything to be programmed has to be programmed in an OO language.
What I got out of the article (which I thought was poorly done) was that the problem isn't OO itself, but that OO is being overly applied where it isn't needed, and even where it gets in the way.
How can OO be a "fad" if ... (Score:4)
As Jim Coplien has pointed out, OO (objected oriented programming / design / analysis) is older today than "structured" programming / design / analysis was when OO first burst upon the scene. (The structured movement first got some serious press in the mid to late 1960s; the classic book by Dahl, Dijkstra, and Hoare was published in 1972. OO started no later than Simula-67 and Smalltalk-72, and first gathered mainstream attention in the 1980 - 1982 timeframe. The first OOPSLA conference was in 1986.)
Yes, some snake-oil salesmen overhype OO
No, OO is not a panacea. It's not even always the right tool to apply to a particular design or programming problem. (Coplien's recent book, Multi-Paradigm Design for C++ [fatbrain.com], is a tough but worthwhile read that addresses this issue.)
You may dislike a particular language that supports OO (Smalltalk, C++, Java, even Perl) but find the paradigm worthwhile in some other language.
For comparison, compare with this message in Risks Digest [ncl.ac.uk]: "The structured programming revolution is a real bad idea that has been significantly holding back progress for years.... Have there been any double blind studies which unambiguously show that the kind of programs that structured programming partisans enjoy are really more maintainable than some other kind of program? I've heard lots of testimonials, but no real evidence." Sound kind of familiar? (Heh.) --PSRC
the key phrase is: properly implemented (Score:2)
Re:Author is a USENET troll/pest (Score:4)
Wow. I think /. has been seriously trolled this time.
Objects & RDBMS (Score:2)
Technology is rarely the problem -- the usual problem with projects and OO is that the zealots win, and centrists who want to use the most-suited technology for the specific application get ignored or called "hacks". The over-ambitious 3-tier agent-based project gets canned, and the "hacks" get called in to fix it using a less long-bearded method.
Re:I tend to agree with the author.. (Score:3)
The guy who wrote the article missed one of the most important aspects of OO, and that's _interface_ inheritance. Interface inheritance is _NOT_ subtyping, and is vastly more flexible and usable than subtyping, which seemed to be one of his big gripes. If you want to know more about interface inheritance, look at my page at
http://members.wri.com/johnnyb/comppapers/facto
I called them "feature factors" here.
People think in objects (Score:4)
Actually it does. But it's a correct one.
One of the basic assumptions is that the human brain is built to think about the world in terms of things that have properties and behaviour. We can think in terms of procedures and execution flow as well, but we're not nearly as good at it.
Re:common misconception (Score:3)
What do you think the "window_init", "window_draw", and "window_destroy" functions were? Just because these functions weren't formally defined as methods of the window_t object doesn't mean that they aren't methods. In the programmer's mind, they're methods, and that's what matters, in the end.
Talk about flamebait... (Score:5)
The article is topped off with a gif image tagged "OOP Stinks!". That should give you a good insight into the level of discourse that follows.
Of course, the author absolves himself from all responsibility for having to present anything more than an emotion-filled diatribe by stating early on:
So... his article is based on debunking "OOP Myths", which he states are not "necessarily shared by all or even most OO proponents." He repeatedly fails to back up any of his points with citations or references (and at one point, actually states "Sorry, we accidentally lost the references.") Instead, he justifies his arguments by making blanket statements like "Many OO books and even some OO fans suggest that OO only shines under fairly ideal conditions." Which OO books? "Some" OO "fans"? (Remember the disclaimer - not neccesarily all or even most OO proponents...)
Finally, some of his commonly (or not-so-commonly - take a look at that disclaimer, again) believed OOP myths are outrageous to the point of being silly... OOP eliminated the need for case or switch statements? OOP makes programming more visual? Only OOP has automatic garbage collection? Components can only be built with OOP? Only Only OO databases can store large, multimedia data? Who, exactly, does believe these myths? PHBs? Certainly not anyone with a CS education or decent amount of programming experience.
The best thing I can say about this article is that I think the author has a few good points and compelling arguments that are, unfortunately, lost amid the noise and confusion of unsubstantiated facts. If you can read it through and keep from grimacing in pain as OOP is compared to communism and the lack of research in non-OOP languages is decried, you might be able to find an idea or two that will reward you for the effort.
In the tiger compiler book (Score:4)
"object: to feel distate for something"
I laughed my ass off (even if I do OO programming since 1991).,
Cheers,
--fred
Good objects are a lot of work (Score:4)
Objects are great where they work, and where you have the time and experience to tune them to perfection. The Python libraries are full of beautifully crafted, wonderfully useful object definitions. But that investment is large, and in many cases, doesn't make sense for the purpose at hand. And there are problem domains for which objects simply aren't the natural description.
The OO people say that the wrong way to reuse code is the cut-paste-tweak method, because then you have two diverging copies floating around. In a perfect world everything might be in a source code repository and I could submit a change rather than spawn a private tweak. But change submissions mean bureaucracy, if I'm working with other people. If my tweak will never see public use, the overhead is an unnecessary diversion.
The cited geocities page makes noise about table-oriented programming. I remember hearing similar things in the past, stuff like "Put the intelligence in your data and keep your code simple". I would have liked to see a better description of TOP, perhaps a few pointers to tutorials. The guy's own descriptions are pretty useless for quickly grokking his point. Maybe he's only preaching to the database crowd, and I'm not supposed to get it.
A cop-out? (Score:3)
Disclaimer: not all myths discussed are necessarily shared by all or even most OO proponents. They are based on "common notions" found in the business and programming world as I have observed them. I am making no claims as to the frequency of beliefs in the myths. My frequency of encounter may differ from yours. Discussing myths is not the same as "punching a straw-man", which some OO proponents claim I am doing by mentioning myths.
So... this is based on his experiences, without research? He has based this piece of writing on merely his viewpoint? Surely, if any technical critic wishes to be taken seriously, he should back his work up with proper figures and research, rather than "myths".
Communism also looked good in theory, but its base assumptions about human nature were flat wrong!
Okay... he's comparing OO with Communism? I don't see the connection. Does OO make assumptions about human nature?
This seems far too much like a rant, backed up with a few web pages... I would not take this seriously.
Re:Another reason ... (Score:5)
Re:common misconception (Score:3)
A data structure is a structure, not an object.
If you add the methods to manipulate the structure (via function pointers if you're using C), then you have an object.
Tell us something we don't already know... (Score:5)
Taco,
Some of us remember what slashcode [slashcode.com] looked like before pudge and friends started cleaning it up.
Not only are you opposed to OOP, but you don't seem to be terrible wild about structured programming either. Nor do you give readibility and maintainability the time of day. Your relationship with elegant code is in the "distant admiration" category and you seem to consider sobriety an impediment to productivity.
Not that I disagree with you on any of these points, I just wanted to mention that we allready know about them.
--Shoeboy
Re:Author is a USENET troll/pest (Score:3)
Actually, most GUI application programmers almost never see the code structure that makes up their screens. They simply click on a screen item, an event selection box comes up (Events like: on_click, on_exit, on_keyboard, etc.), and then a "code snippet" box comes up to edit the event code. Whether that event code is in a method or subroutine does not matter that much to the programmer. If you changed the generated code implementation from OOP to procedural and/or tables, the programmer may never even know the difference.
This is not a programer!
Poor criticism (Score:5)
In general, the criticism contained in the article is poorly founded. The author uses some nice charts, but has no citiations for them. For instance:
Accepted by whom? I've never heard that asserted by anyone in my academic or professional careers.Some of the things he calls out apply equally to procedural languages, such as:
When Pascal replaces C, how do I convert my C functions into Pascal functions? Eh?He makes some good points about measuring the effects of change (everybody should do that!) but I don't think this really strikes a death blow to OOP.
Neutron
Re:common misconception (Score:5)
That isn't saying it's a good a idea.
--
Bush's assertion: there ought to be limits to freedom
Re:common misconception (Score:4)
OO is just a handy way of structuring large systems for maintainability. It is extremely useful for what it does, but isn't magic.
People who dismiss OO out of hand are making the same mistake as zealots who insist that it must be used for everything by rejecting a useful tool.
Structured programming, functional programming, OO etc are all extremely useful given the right problem domain. The skill is being able to look at a problem and pick the correct tool for the job. Rejecting, or choosing, something automatically can be a very good way to shoot yourself in the foot.
Re:reusability... (Score:5)
Properly implemented, code re-use can pay off immediately. I have worked in shops where every time we added a client, we needed a new copy of the code. Even though most of the processing was the same for the new client, we had to start out with a copy of the code. Code re-use would have bought us hundreds of thousands of dollars very quickly. (This did not ocurr at my current employer)
Properly implemented abstraction and OO along with iterative design can save a large amount of money very quickly. The key is to prototype your interfaces for the application you have in mind. Once you have done that, think of a completely unrelated use of the interface and test that. If you can handle 2 or 3 different uses, you have a good interface to start with. Rinse and repeat for the rest of your system.
People may question you immediately, however the minute somebody decides to change the system message transport from http to JMS, you should be able to convince them of the value of proper abstraction and code reuse, just change the transport class and you are done. I did this in a system where we did all of the work necessary to change the transport in less than 30 minutes. The consultant that had been working on the same problem for 3 months was absolutely amazed at quickly I made the change.
OOP is not a cure all, however its use along with proper abstraction can lead to large savings from code-reuse in a short time.
Mike
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com
Another reason ... (Score:4)
I'm a sometimes chip designer, sometimes programmer ... a while back while working on an unnamed CPU project I did some low level performance analysis on a number of well known programs (maybe even the browser you're using now) basicly we were taking very long instruction/data traces and then modelling them against various potential CPU pipeline/tlb/cache architectures - we were looking for things that would help guide us to a better architecture for our CPU.
I found that quite early on I could figure out which language something was coded in from the cooked numbers pretty easily - OO (ie C++) coded stuff always had a really sucky CPI (clocks per instruction - a measure of architectural efficiency that includes pipe breaks, stalls and cache misses) - I spent some time looking at this (since it seemed that C++ code would probably become more common in our CPU's lifetime) - basicly C++ code sucked because it took more icache hits (because the coding style encourages lots of subroutine calls which tend to spread over the cache more filling the I$ quickly) and it took more pipe breaks (also due to the subrotine calls and returns - it turned out that some code generators did stuff that broke CPU's return stack caches causing many more mispredicts) and finally virtual method dispatches (basicly load a pointer, save the pc on the stack and jump to the new pointer) tended to cause double pipe stalls that couldn't be predicted well at all even though these weren't done much they were a real killer (if you've one a bit of modern CPU architecture you learn that with long pipes you live or die on your branch predictor's hit rate - these were very bad news)
In short C++ and more genrally OO result in code and coding styles that tend to make code that makes modern CPU's run less efficiently.
Anyway - you often hear about 'efficiency of programmers' etc etc for OO - I thought I'd add a data point from the other end of the spectrum.
No Magic Bullet. (Score:3)
Programmers just need to be familiar with multiple programming practices and languages. Programmers need to know when just hammering out some _properly_ planned procedural code will fit the case better than some _properly_ planned OO code. There is no magic bullet and because of this, I think it's a bit pointless to say that one programming style is leaps and bounds better or worse than another.
I really wish the author had the confidence in the claims to actually site some hard facts and not some made up claims. Most of the article just seems like old rehashed FUD from the dawn of the OOP movement. The author mentions all of these failed business apps and blaims OOP for their problems. I guess IBM, Oracle, NASA, and some of the other big software shops are a bunch of idiots for doing any OOP. But of course this guy must be an expert on software design practices and that's why he has a Bell Labs URL.
Re:common misconception (Score:3)
Well, OOP should be used for things where the data structures resemble (in some way) real-world objects. For instance, games and other things that simulate physics can benefit from object-oriented design. Databases with dissimilar chunks of data might be easier to deal with using OOP. It may be helpful to represent other computers or programs as objects, in applications that require large amounts of intercommunication and response.
OOP essentially downplays procedural programming, but (at least I) tend to find many things procedural, which would have to be twisted up to fit into the OO paradigm. Anything that does an easily-definable process, such as most system utilities and so forth, is probably not suited for OOP. Back to games, I recently wrote a 'roguelike' game: although the code dealing with monsters and items was somewhat object-oriented, the game logic itself was procedural. Programs that primarily deal with large amounts of raw data should probably deal with it in a procedural rather than OO manner.
Author is a USENET troll/pest (Score:5)
Herbie J.
Polymorphism (Score:3)
The author doesn't describe in depth what I consider one of the greatest advantages of object oriented programming -- polymorphism. Polymorphism is great because it allows you to invoke different methods for the same operation based on the derived class.
That makes more sense with a real example. I'm working on a set of classes that has a Stream abstraction. Derived classes must provide ways to do raw reads and writes, close the stream, and a few other things. (Preferably, they also provide some way to open the stream -- but that's not a virtual function.) The stream class itself provides buffered IO and some convenience functions for writing stuff in network order, a nice gets function, etc.
That allows me to have the same easy IO operations on top of many different kinds of streams:
Each one of these provides the same basic abilities -- reading/writing, seeking/telling (where applicable), closing, etc...but they do it in different ways. I need abstract read/write code so I can put shared higher-level code on top of it. Otherwise, I'd have to reimplement the higher-level code for each one. That would suck.
This doesn't even necessarily need an object-oriented language, just an OO concept. OpenSSL, for example, has a set of C functions that do a lot of the same things I'm talking about. It does it by providing a struct with function pointers...basically, a virtual function table. It's definitely not as pretty (I wish they would have just done it right and used C++) but it does work.
This is just one advantage of object-oriented programming, but I think it's a very significant one. Worthwhile by itself.
Re:My view (Score:4)
"If an object is data with functions, then I've been doing object-oriented programming all my life"
Generally when people talk about "OOP" they're referring to three general things you'll find in an OOP language:
Sounds like you've done mostly encapsulation, maybe a bit of inheritance is natural too. Probably not polymorphism though.
The thing about OOP is, although it supports these concepts in the language, it doesn't automatically lead to good design, and that is the point that the author of the article this whole thread is about seems to have missed. You still have to think about your design very carefully to build good reusable components. In general it does make you think a little bit more carefully before you just start coding away, which isn't a bad thing. There is nothing you can do in C++ though that you can't do in C. C++ just lends itself more readily to expressing certain types of ideas within the language's native syntax, e.g. picture the "gtk+" toolkit without all the ugly hacky typecast macros and the hacky inheritance structure.
Presumably there are some OO zealots out there (I personally don't know any but the article author seems to think almost every C++ programmer is an OOP zealot) but in general I think most OOP programmers are more focused on solving real-world problems than on spreading hype. For every rabid OOP zealot, there's a rabid anti-OOP zealot. This guys just one of the rabid anti-OOP zealots. When you really do speak to most people in the business, they *dont* have big issues about programming paradigms. They just use the best tool for the job and are actually mature about it.
OOP *is* really the next level (Score:3)
There are applications - small ones - for which OOP is not appropriate. Code which generates web pages, for example, is generately best written in a procedural language. The vast majority of applications, however, are easier to extend and maintain (although not necessarily write, at least until you've been doing it for quite a while) if written with OO.
And of course, you don't need an OO language to use OO. The Linux kernel is very OO, and it's written in C.
FWIW, the examples given in this article are terrible. Not only are they not very relevant, but they are badly written. If someone I was working with wrote OO code like that, I'd seriously question their ability as a programmer.
Re:The King of Argument By Authority (Addison) (Score:4)
My experience in systems design is that OOP shows benefit when you know it, and with larger *REAL* systems. Networked apps, distributed apps, and yes, even large business apps. I've been involved in an IS project written completely in C, using good, structured programming techniques. At a different company, we were building a similar application, using C but applying a more data-centric approach, close to OOP but not there yet. It was much quicker to build, and easier to enhance. If I took a crack at the domain yet again with OOP and C++/Java, I know it could be improved yet again.
The issue though, is that if it's one guy, building a one-shot fire and forget app, don't bother. Code it however you want. If you have a significant project with multiple team members, OOP acts as a common framework and a basis for communication. It draws some borders and sets some guidelines and methods to give a common frame of reference. It's possible, but more difficult to do that with procedural code in *most* cases.
Obviously though, the proof, as the author says, is in the pudding. Millions upon millions of development dollars is OBVIOUSLY being wasted by the industry as it moves to use OOP methodologies and tools. Not just as dictated by PHBs, but also as dictated in start-ups by lead programmers.
Quote from a pundit who knows the industry better than most of us, Robert Cringely, from a slashdot interview no less:
Something else that has changed a lot is how software is written. OOP has paid off more than we even know, so there are a lot of chances to make businesses out of selling cogs that fit into other people's machines. Your driver question, for example, wouldn't have even made sense a decade ago.
Hmm. More than one company now. There's a benefit. Predefined interfaces and component technologies. Can you do that in procedural approaches, yes. Is it easier and more natural and efficient in OOP, yes.
And finally, as I don't want to get too long, let's take another /. post, a reply from John Carmack.
First of all, the fact that none of our deployed games used OOP does not mean that I don't think there are benefits to it. In the early days, there were portability, performance, and bloat problems with it, so we never chose to deploy with it. However, all of the tools for DOOM and Quake were developed in Obejctive-C on NEXTSTEP. Q3 also came fairly close to have a JVM instead of the QVM interpreter, but it didn't quite fit my needs. I'm still not a huge C++ fan, but anyone that will flat out deny the benefits of OOP for some specific classes of problems like UI programming and some game logic is bordering on being a luddite. I still don't think it is beneficial everywhere, but, if anything, I think we are behind the curve on making the transition.
Hmm. Use the best fitting tool. But even a die-hard success phenomenon like John Carmack seems to think OOP is good for things link UI AND game logic. Not everywhere. No argument from me.
Jeez, I think he essentially can be construed as having called the author of the original post a luddite.
I tend to agree.