Talk:Object-oriented programming
From Wikipedia, the free encyclopedia
|
|
 |
This article is within the scope of WikiProject Computer science. | |
| ??? | This article has not yet received a rating on the assessment scale. | |
| ??? | This article has not yet received an importance rating on the assessment scale. | |
Contents |
[edit] need to add an example of multiple inheritance
In the bulleted paragraph describing multiple inheritance, the statement "When an object or class inherits its traits from more than one ancestor class, it's called multiple inheritance." seems to say that 'Lassie is a Collie, a Collie is a Dog' is an example of multiple inheritance, when it is not. An example of multiple inheritance could be added, perhaps where a Collie and a Chihuahua breed; the offspring would inherit from both the Collie and the Chihuahua classes. This example would illustrate the complexities of multiple inheritance, because the offspring would be able to tremble(), but confusion arises as to which bark() to use, either the high-pitched Chihuahua.bark() or the default Dog.bark(). Spemble 16:08, 3 January 2007 (UTC)
- I think the Chimaera example is quite clear: a Chimaera isa cat anda dog. For another example:
- aircraftCarrier isa ship.
- ship isa vehicle.
- twoWheeler isa vehicle
- and
- nuclearReactor isa primeMover
- pedal isa primeMover
- then you can have a couple of new classes using multiple inheritance:
- nuclearAircraftCarrier isa nuclearReactor-powered-ship
- bicycle isa pedal-driven-twoWheeler
- There are also some more classes you can have, but knowledge tells you that they cannot exist, such as a pedal-driven-aircraftCarrier and a nuclearReactor-powered-twoWheeler, though probably both might be fun... Dpser 16:44, 26 January 2007 (UTC)
[edit] Removal?
Who keeps removing the link to the Richard Mansfield article? If it does not "qualify", please state why.
And I removed the opening "real world" claim for reasons given later in the wiki article (3.3). —The preceding unsigned comment was added by 66.120.226.1 (talk • contribs).
- I removed the entire external links section, not just this one particular link, because none of it met WP:EL. Wikipedia is a collection of articles, not a link farm. Other people may have removed just this specific link in the past, and I can't speak for them; I can only talk about why I removed the external links. We should add verifiable, cited content to this article rather than a bunch of links to various people's opinions. The "further reading" section is in my opinion listcruft and probably needs to go, too. The books/articles which are citations should be moved to references, and those which are not citations should be removed from the article.
- Now, about this link in particular. The Mansfield article does not meet any of the "What should be linked" criteria in WP:EL. It doesn't appear to me to be a reliable source. It's one guy's opinion, without a single citation nor even a real-world example. He states that OOP "isn't doing what it promises" without saying who, exactly, is doing the promising or what they are, precisely, and then compares it to Marxism! This is not research, it's a screed, and while he's more than welcome to post it on devx (more power to him, frankly, for speaking his mind), it doesn't meet Wikipedia guidelines for what should be cited or linked and doesn't belong here. --Craig Stuntz 21:02, 10 January 2007 (UTC)
How is this different from Bertrand Meyer's opinions and rants in his often-cited book? There is very little proof of OOP being better anyhow. Thus, if we only stick to science, then this entry would be real short. OOP is largely a psychological phenomena, not a scientific nor mathematical one. Mansfield is the author of several technology books, I would note (but not directly about OOP). And, devX is published material. —The preceding unsigned comment was added by 68.183.137.111 (talk • contribs).
- Well, Meyer doesn't run up against Godwin's Law, for starters. Seriously, are you really not able to see the difference between Meyer's book and the devx article? I find that difficult to believe, especially as I know you've read both. The point is not that Mansfield is somehow less of a reliable person than Meyer, it's that this specific piece by Mansfield doesn't even attempt to justify its assertions. Yes, Mansfield is capable of writing a cite-able source; he just didn't do it in this specific case. Oh, and the article does not claim that OOP is generically "better" (or worse, for that matter), nor should it. Assertions that a particular development methodology is "better" or "worse" are suspect by their very nature and certainly out of place in an encyclopedia. --Craig Stuntz 14:08, 11 January 2007 (UTC)
- No, I don't see much difference. Meyer does use shape and animal examples with code, but those don't extrapolate to real-world problems. And he has several flaws in his reasoning, but we can't consider those because they are "uncited". Wikipedia is growing stale by limiting opinions and links. —The preceding unsigned comment was added by 68.183.137.111 (talk) 04:15, 14 January 2007 (UTC).
the authors discuss inheritance with regards to an example of a circle which is a subtype of an ellipse. Other than redefining a data type to represent an object with two foci (which are the same if it is a circle) they find very little utility in inheritance beyond the what can be provided via a database view, which uses the well-known normalization transform of a super type sub type relationship. IMHO anything beyond this "inheritance" is pure garbage, and cannot be supported be rigorous theory.
For example, read http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0130648841/ref=cm_cr-mr-title/103-9197091-7991048. There are many "Patterns" such as the Business Delegate, but no rigourous, mathematical formulation of why they exist or are helpful compared with other alternatives. -Anon.
-
- Gentlemen. This is not the place to debate the merits of OOP; this is the place to discuss the article. People's personal opinions of inheritance, etc. (and I agree that inheritance is quite frequently abused) aren't relevant here. There are many notable critiques of OOP in various contexts (Chris Date is generally a reliable source; though he avoid comment on OO outside the scope of databases) without happing to cite unreliable sources like tablizer, this Mansfield article, etc. Go find them. :) If you want, write an article about the Circle-ellipse problem; it's certainly deserving and lots has been written about it. --EngineerScotty 19:04, 19 January 2007 (UTC)
-
- The circle-ellipse problem is not very practical in my opinion. Too many OOP books use shape, animal, and device-driver examples. They may be okay for studying philosophical concepts or basic training, but they are difficult to apply or compare to more real-world problems. At least "tablizer" uses banking and power utility examples. --Anonymous.
-
-
- Non-sequiter for several reasons: 1) The above comment concerning tablizer.com was not made because I like or dislike the page in question; it was made simply because tablizer.com doesn't meet Wikipedia's requirements for a reliable source. It's self-published and not peer-reviewed, it's ignored by the literature, and tablizer isn't recognized as an expert in the field. (For that matter, tablizer doesn't even like his real name being printed). 2) The circle/ellipse example is entirely appropriate, as it illustrates a basic issue. That said, the OO literature is full of examples of complex applications being implemented beyond shapes and critters and what tablizer (and you--assuming you aren't him--if you are User:tablizer you should log in rather than pretending to be an anonymous third party) refers to as "device drivers". At any rate, I'll work on the circle-ellipse page; there's a good start there. --EngineerScotty 18:27, 22 January 2007 (UTC)
-
-
-
- I would like to see citations for "examples of complex applications being implemented beyond shapes and critters" (and device drivers). For example, comparative business applications. I don't dispute that such examples run, but I dispute that there is any literature that clearly shows how they are objectively better than procedural/relational equivalents. The scientific case for OOP for business applications is nearly non-existent. --Tablizer 04:45, 29 January 2007 (UTC)
-
-
-
- PJTraill 19:16, 20 January 2007 (UTC) I have written Circle-ellipse problem.
-
-
-
- They are certainly not! Object-oriented programming is about programming and not run-time efficiency. The end-product can very well be exactly the same. Or in some cases it may be even better if you use procedural programming and relational knowledge. It is not about the result, it is about the methodology! If you understand your world better using relational knowledge that's all right. Other people identify objects within their representation of the world, that's also not bad either. For example I don't have to worry about whether Mrs. Simpson has a beard. For a relational database this is of course an issue. And it may be right after all, but for me it is just a matter of taste. However, I think it is clear that the article is about object-oriented programming and disputes about whether the end product is better or worse are wrong, because this is not the issue.Dpser 12:41, 29 January 2007 (UTC)
-
-
-
- Could someone please clarify where run-time speed was brought up as an issue? There seems to be a speed-related response, but no original matching statement.--66.120.226.1 20:57, 1 February 2007 (UTC)
-
-
-
- Discussing whether OOP is "better" (or "worse") than other methodologies completely misses the point. The article makes no claim that OOP is "better" or "worse," nor should it. The article is intended to describe OOP, not advocate an opinion about it. --Craig Stuntz 14:53, 29 January 2007 (UTC)
-
-
-
-
- Agreed with Craig. To address top's point--there isn't literature which "clearly shows" that other paradigms (relational, functional, procedural, what have you) are "objectively better"--and as you've pointed out long and loud at other forums, such comparitive studies are highly difficult. Lots of people who can be considered experts--Chris Date, Peter Norvig, Bertrand Meyer, to name three, have weighed in on the debate; feel free to add cites from these on the subject. But as Craig points out, this is not an OO or relational advocacy forum. We're not here to decide which is better. --EngineerScotty 16:35, 29 January 2007 (UTC)
-
-
[edit] Timeline
- Object-oriented programming developed as the dominant programming methodology during the mid-1980s,[citation needed] largely due to the influence of C++, an extension of the C programming language.
No way. I remember my first job in 1986, and everyone was using C. Mid 1990's, maybe. And as far as I know, it was "largely due" to Java. I know this because I happen to be a Java programmer (persons with no sense of irony, please do not reply to that).
Paul Murray 05:52, 31 January 2007 (UTC)
- I think 90s is more accurate, and I think C++ and Java would be more accurate. But I'm reluctant to change it from one person's recollection to my own without a good source. --Craig Stuntz 14:24, 31 January 2007 (UTC)
OOP was not dominate in mid-1980's due to C++ or anything else. COBOL was still dominat in the 80's - University courses not-withstanding. And despite C++ being an improvement over C, it wasn't much used for OOP (again outside of University courses). OOP didn't gain any real traction until Borland Object Pascal and Delphi put it in the hands the business programmers so they could study it up close. But OOP couldn't begin to claim dominatation until JAVA became the lingua-franca for the new class of business systems (client-server/web-based) starting to be developed in the late 90's. Complete legitimacy in the business world was achieved only when SAP added OOP to ABAP in the early 2000's. -- HKL47 04:06, 15 March 2007 (UTC)
[edit] Argumentation unclear
"Pure" object-oriented languages, on the other hand, lacked features that many programmers had come to depend upon. To bridge this gap, many attempts have been made to create new languages based on object-oriented methods but allowing some procedural features in "safe" ways. Bertrand Meyer's Eiffel was an early and moderately successful language with those goals.
I do not understand what this means: which constructs were added in Eiffel (so much that it can be seen as a goal of the language) to support procedural features that many programmers had come to depend upon? --Schoelle 23:37, 23 March 2007 (UTC)
