Talk:Object-oriented programming/Archive 1

message: I also think that this page isn't about Object-oriented Programming, but about Object-oriented languages, or structure. I picture an entry on Object-oriented programming giving information about programming, not the languages underneath.
But my real question is about strict OO Languages. What does it take to be truly OO? I've heard it argued (its being argued in my apartment of 4 CS geeks ATM), and I've seen textbooks say that C++ isn't strictly object-oriented, but is merely object-compatible. Any thoughts on the matter?
McKay 07:12, 2 Aug 2004 (UTC)
replies: text: Pure OO implies that everything is an object, and that the only way objects can communicate is through sending messages. This implies that C++ isn't pure OO, neither is Java (it has non-object primitive types and it has non-oo imperative control structures). Smalltalk is an example of a Pure OO language wlievens
I think it would be useful to include this definition of "true" or "pure" OO
somewhere in the main article. (anonymous user, but I promise to register one
of these days)
--80.62.49.62 13:44, 7 Jan 2005 (UTC)
thread_title: Truly Object oriented

message: Nobody has mentioned here, why we call this object oriented. Many believe the reason for that is because of the presence of the objects. However the truth is that the term Object Oriented comes from the grammar and this was a significant shift from the Subject Oriented programming style that existed. A program specification says "System checks the Catalog to find the price of the item, System records the transaction, System prints the receipt, etc". Since we used to think from the subject side the complexity of the subject (here the System) increased with the complexity of the requirements. Then the researchers started thinking in an object oriented way where by the verb of the sentence in the requirement is attached to the object. They found that they could create much better and structured application by reading the specification like "Catalog checks the price on a message from the System, Transaction records itself on a message from the System, Receipt prints itself on a message from System, etc".
-- harinair Jan 05, 2005 17:20 PST
Wow. I would like to see a reference on this.--Donaldino 19:25, 14 November 2006 (UTC)
thread_title: Term Object Oriented comes from Grammar

message: 2.1 Actor model has a lot of bla-bla on "modules", and makes some really strong claims about the fact that the main purpose of OOP is to modularise source text. Imho, OOP is a design philosophy and can be applied to visual programming just as well. Wouter Lievens 22:41, 13 Jun 2005 (UT
IMO the section on the actor model does not belong in an article on OOP.--Donaldino 19:17, 14 November 2006 (UTC)
thread_title: 2.1 Actor model

message: the value of inheritance in these languages is often questioned <-- I'd really like a source on that. Wouter Lievens 21:45, 17 July 2005 (UTC)
replies: text: I think this sentence is bogus. /Misuse/ of inheritance could be criticised but all languages I am aware have some form of inheritance (static or dynamic), even classless Io programming language. Pavel Vozenilek 23:50, 17 July 2005 (UTC)
thread_title: 6 OOP in Scripting

message: While many Smalltalk advocates will protest loudly... I generally consider the use of the term message to mean a synchronous (caller blocks on receiver until receiver returns) method call to be confusing. Apart from the looser coupling involved; a Smalltalk message send is not fundamentally different from a method call in C++ or Java; and has nothing to do with the most common use of the term "message" in computer science--namely, part of an asynchronous communications channel.
Those familiar with Smalltalk history will know the etymology of the term "message" in the Smalltalk context. Early Smalltalk dialects were based on a programming model resembling the actors model; and message sends really were asychronous communications between different tasks. However, that architecture was abandoned in Smalltalk-80. Yet the terminology stuck. As OOP was still in its infancy in the late seventies and early eighties (and the actors model of only academic concern), there was little reason for the Smalltalk team to select a different name. Twenty-five years hence, however, the term "message" is primarily used to refer to asynchronous channels.
--EngineerScotty 22:45, 1 September 2005 (UTC)
thread_title: Use of term "message"

message: I simplified and clarified; I eliminated forward references; I provided an example for each concept; I added a discussion of Class; I attempted to build from simpler concepts to more difficult concepts; I attempted to tie it all together with the example of raiseRuckus().
I deleted the discussion of mesage sending, because message sending is irrelevant to object-oriented programming; for example, IBM's MQ Series is a message-sending system that has never in the least way been associated with object orientation.
I found the statement that "Each object in the system serves as a model of an abstract 'actor'", but since an object is never a model and never an abstraction and it's confusing and unhelpful to bring in "actor" here, I eliminated it. I suppose the writer meant "class", but now that's already covered above.
I found too vague the statement that when "processes, functions or methods are abstracted, . . . a variety of techniques are required to extend an abstraction", so I eliminated that as well.
: T00h00 writes (but doesn't sign!) the following statement:
:: "message sending is irrelevant to object-oriented programming"
: Um, excuse me? You do know that "message sending" doesn't strictly mean message queues, right? A "message" refers to how objects communicate in OO systems. Try a Google search for Smalltalk messages. See, for example, the message passing section in the Smalltalk article. The term is more common in languages which use dynamic binding. This term is less common in contemporary languages like C# than in classical OO theory, but saying it's "irrelevant" is just misinformed. --Craig Stuntz 04:54, 11 December 2005 (UTC)
replies: text: Oh, also: The notion that polymorphism and inheritance are closely related is true in some languages, but by no means all of them. Polymorphism means that different classes can respond to the same message (method call) differently, full stop. It can be done via interface inheritance or by dynamic binding, to name two methods of achieving polymorphism, but that's an implementation detail. Again, your comments seem to have a view of OO which is very close to what some languages do but not others, and in particular exclude the languages and environments which founded object orientation — Simula, Smalltalk, etc. I'm going to correct the polymorphism / inheritance comments since it's IMHO misleading. --Craig Stuntz 14:31, 12 December 2005 (UTC)
thread_title: Major rewrite

message: How about some simple code snippets to showcase basic differences between OOP and the alternatives? — Simetrical (talk • contribs) 22:04, 11 January 2006 (UTC)
replies: text: Unfortunately, coding styles are so various, the examples would be trivial or, worse, caricatures of the different styles. Myself, I have been using what I would call OO-flavored code (because of my analog background and real-time applications career) over at least 40 years — well before coders discovered OO and OO languages were invented. (But, it's real hard using macros in assembly language or using Fortran II. In the latter, you can't even fake re-entrancy, so object "instances" are not possible.)
However, you might suggest external references illustrating coding styles.
 — >normxxxtalk — > email 22:03, 13 January 2006 (UTC)
thread_title: Code snippets

message: Normxxx had some problems with a version of my rewrite.
Im fairly good at editing and rewriting, and the article definitel needed it. But I am more than willing to defer to experts on any specifics, as long as experts defer writing to expert writers. -MagnaMopus 01:00, 9 February 2006 (UTC)
thread_title: Edits to lede

message: I'd like to suggest revision of this section, which discusses the proposition that OOP eases modelling of 'real-world phenomena/objects'. It appears to restrict the benefits of this approach to models of physical objects, pointing out that 'many domains ... have no substantial physical counterpart'. This misses the point that any computer model of the 'real world' is of necessity an abstraction. This is as true of a vehicle simulator as it is of an investment management system.
Countersubject 12:11, 26 May 2006 (UTC)
replies: text: I tend to agree. The section has a "he said/she said" feel which doesn't really fit in an encyclopedia, in my opinion. --Craig Stuntz 12:53, 26 May 2006 (UTC)
thread_title: Matching Real World

message: Factor formerly contained this text:
an acronym for Functionality, Application domain, Conditions, Technology, Objects, and Responsibility in the OOA&D method
OOA&D redirects here, but this article says nothing about this acronym (or OOA&D, for that matter). It looks like we're missing information. --Smack (talk) 18:00, 18 July 2006 (UTC)
thread_title: FACTOR and OOA&D

message: Pehaps the critique section should be divided into sub-topics with a pro and con section for each. Rough draft:
* Structural
** Hierarchies and the "real world"
** Navigational (networks of objects and object pointers)
** Set-theory proposed as superior or equal to hierarchies and navigational
* Behavioral
** OOP tends to present a behavioral interface, but declarative (data-centric) interfaces allegedly have more "maths" and discipline to them.
* Database
** Schemas and classes allegedly overlap too much
** Wrapping databases allegedly will result in reinventing features already offered by databases and creates unnecessary layers that translate across paradigms instead of increase abstraction.
** Relational allegedly offers more discipline than OOP (related to "structural" above.)
** OOP lacks any built-in concept of Collection Oriented Programming.
The problem is that most of these complaints are partially interwined such that it is hard to describe in a non-overlapping way. — The preceding unsigned comment was added by Tablizer (talk • contribs) .
: It's getting worse now. It's not only unstructured, but it's filled with un-cited, unencyclopedic, anonymous, he-said / she-said blather. Rather than an endless point-counterpoint between nameless "supporters" and "some critics" we need cited references to criticism from people who actually understand OOP well enough to criticize it. {The problem is that there is no universal measure of "understand". People tend to accuse their opponents of "not understanding" in these debates. --Tablizer 08:46, 9 September 2006 (UTC)
replies: text: I'm tempted to remove everything which is un-cited, but that would leave the section empty, and I don't want to give the impression that there is no criticism or even no informed criticism. But I do think that no information at all is better than verbiage which is misleading and scarcely readable. --Craig Stuntz 17:34, 4 August 2006 (UTC)

text: You have some very good points. However, I believe that the criticism section should primarily point to the sources that list the criticisms and let the sources do the talking themselves. I am working on a rewrite because I find the current criticism section to be inscrutable. I am going to significantly shorten the section and provide many references.--Andrew Eisenberg 01:09, 8 August 2006 (UTC)
replies: text: "Pointing to the sources that list the criticisms and letting the sources do the talking themselves" would violate Wikipedia policy. The article should speak for itself because Wikipedia is not a collection of external links. References are to be used so that readers can verify the information in the policy, not as a substitute for article content itself. Text in external links can't be edited by Wikipedia users, so using this as a substitute for article content violates the wiki process. We are writing an encyclopedia, not a web directory. --Craig Stuntz 12:58, 8 August 2006 (UTC)

text:  The problem is that some fuss about such links not being "official research" (which is a dying breed in the web days). The problem is that there is very little official research on the topic. I thus suggest at least some kind of breif attempt to categorize and describe the criticisms. The problem is that it is hard to sum up the complex, multifaceted arguments in breif paragraphs. Thus perhaps simply mentioning the criticism categories with links may be the least of evils. --Tablizer 08:46, 9 September 2006 (UTC)

text: But some see the difficulty mapping between them as a reason not to use OOP. It allegedly does not "play nice" with relational. There are a lot of complaints about the tediousness of OR-mappers. Other non-OO techniques allegedly have fewer problems with mapping because they generally let the database house the "noun model" rather than application code. UML diagrams that resemble ER-diagrams are an example over the conflict of which side has responsibility for "noun modeling". Other paradigms tend to "give in" to the RDBMS rather than try to wrap it away. --Tablizer 08:52, 9 September 2006 (UTC)

text: The correct place to have criticism would be here, not in a POV fork. The problem with the old criticism section was not length -- it was actually quite short -- but that it was a collection of scarcely-coherent weasel words which were often un-cited, sometimes contradicted by their "sources" when they were cited, and frequently used un-verifible sources, i.e. some guy with a web site rather than peer-reviewed literature. Some of the "criticisms" faulted OOP for failing to solve every problem in programming, something which no paradigm will probably ever be able to claim. I did start collecting good citations for a new criticism section elsewhere on this page, but have not had time to finish the project. Others are welcome to contribute to the list. --Craig Stuntz 16:36, 17 September 2006 (UTC)
thread_title: Cleaning Up Critique Section

message: Regarding the grammatical examples:
# Subject-oriented: The Sales Application saves the Transaction (6 words)
# Object-oriented: The Transaction saves itself upon receiving a message from the Sales Application (12 words)
I find it amusing that the object-oriented sentences in the examples contain exactly twice as many words as the subject-oriented sentences. So much for simplification. ^_^
* Those are really bad examples anyway. Nobody would really write requirements such as what is offered as the Object-oriented version. Despite the fact that OOP focuses on the nouns, it does not change the source requirements (which seems to be what is being offered there) in any way, only the analysis of those requirements changes. So the whole examples are very weird, in my opinion. In my opinion, there is no "translation" of "subject-oriented" thinking into object-oriented thinking. It would be more appropriate to say that in OO analysis, nouns from the requirement statement are analysed *first*, which produces the conceptual model, then the concepts identified are populated with actions that they can perform. Only the *order* of analysis steps is different. The result, of course, is much different, because different things are considered as "big". esap 20:32, 2 August 2006 (UTC)
thread_title: Subject/Object oriented senteces

message: While perusing the WANT ADS recently, I concluded that there is an orthodoxy and prejudice grown up in favor of OOP/OOA/OOD. I suppose there are reasons for this. Objects do partition a solution into what can be readily understood interacting parts (no guarantee). Reasonable system design can result from thinking about how a solution can be constructed of well-defined interacting objects. In practice, however, when formal OOD takes place, the reasons each class was put into the solution are usually lost. That's because nobody does documentation anymore. Writing about software is not fun. Maintainers are left with the hen scratchings left behind when the original programmer is long gone. Use of good naming can help maintainers understand programs that lack documentation. But that probably isn't enough. Plenty of commercially successful and reliable programs have been written without object-orientation. Ergo, OO is sufficient, but not necessary. One might conclude that OO is a security blanket for frightened IT managers. The aphorism "Nobody was ever fired for buying from IBM." can be updated to "Nobody was ever fired for requiring object orientation." And what about metrics that show this OO implementation is better done than that OO implementation? OO is better than nothing, and it does have an allure, but it does not prevent lousy programming.--70.108.194.103 18:14, 30 July 2006 (UTC)
thread_title: Panacea

message: added a list of common mistakes which is good but perhaps too broad. I suggest that mistakes which are common in all forms of software development and neither particularly more or less common in OOP be removed, and things particular to OOP be kept. For reference, here's my view on that, although others may differ:
; Common mistakes in general software development
# Confusion between levels of abstraction
# Confusion between application and platform
# Confusion between policy and implementation
# Confusion between "uses" and "is-allowed-to-use" relationships
# Confusion between run-time and compile-time
# Confusion between levels of detail
; Common mistakes unique to or significantly different in OOP
# Confusion between types and interfaces
# Confusion between interfaces and implementations (this is similar to the above and in some languages identical to the above)
# Confusion between function application and message passing
# Confusion between aggregation and inheritance
; Hard to classify without clarification — presently too vague
# Confusion between types and roles
# Confusion between concepts and classes (if you mean that decomposing problems into classes can be tricky then that's true but there are very strong parallels in any modular development, not just OOP)
Anyway, I think it's a good topic for the article, so please don't take my feedback as negative. I just wanted to talk about stuff before I went chopping things up.--Craig Stuntz 17:54, 11 August 2006 (UTC)
replies: text: I agree that maybe it's too broad for OOP article. I tried to list things that I have seen people be confused about when discussing OOP. Many of them are clearly more general than just OOP things. For the vague parts, here's some clarification: With confusion between 'types' and 'roles', I meant the problem some people have when classifying things with class diagrams, where people use just classes (which they confuse with types) and associations, but forget about role (types), and instead attempt to cover for this by using inheritance (inventing a separate class that inherits from a common base for each role), or try to make objects change their type dynamically, or some other overly complex approach to modeling. The references I put in were intended to clarify the meaning. With confusion between 'concepts' and 'classes', I meant the distinction between analysis and design concepts, and possible blurring between those, e.g. where analysis concepts will include concepts needed only because decisions were made for technology or other internal development reasons before modelling e.g. things you are likely to see in design-level class diagrams, or where OO designs are used like they were requirements. It's possible my choice of words in these cases were not the best possible. I'm open to all improvement ideas. Please just make the changes in the article. Thanks for the comments! I changed the wording on some of the entries to make them clearer. esap 17:02, 23 August 2006 (UTC)
thread_title: Common mistakes

message: This paragraph spends alot of time on abstract explanation, explaing the concept, but gives no reason for it. (Im a PHP programmer) why would I want to hide propertiess in classes from other classes? Surely they would all be held on a secure server? Why should you hide attributes? This should be explained.
* Common Mistakes
This section is very amiguous, i would think that short implications of these examples should be provided. eg. I am close to getting my head around OOP but none of these examples make any sense.
: I've added implications of most of them. esap 17:23, 1 November 2006 (UTC)
replies: text: For starters, one could want to encapsulate in an extensible program: what is a sandboxed environment but encapsulation of sorts, if that metaphor works for you. Similarly, what if one does not trust one's fellow programmers to only use the provided APIs and interfaces? More to the point, think about the Unix commandline: all the commands work together so well because each is basically a black box which says it will do something, but not how. Don't functions work the same way? They say they will do something, and take an input and return an output - but any calling functions or programs have no idea how they did it, and so improvements can be done separately and relatively independently. (Does any of that help you out?) --Gwern (contribs) 01:41, 7 October 2006 (UTC)
thread_title: Encapsulation

message: I believe most of these explanations are SO abstract, that some one would not be able to understand the concepts behind them with more
concrete examples. Perhaps having a subjective program example and then demonstrating how it would translate to OOP will give readers a better logical base for undrestanding the OOP concepts. I say this because, for me the logic of subjective programming "flows", in the sense that it is based on simple understandable steps and statements and not on compound sentances where all of these steps and statements need to be understood and conglomerated into a whole before the idea sets into understanding, much better than OOP logic.
For e.g.
"A class should typically be recognizable to a non-programmer familiar with the problem domain, meaning that the characteristics of the class should make sense in context."
One needs ample circumstantial experience grounded in examples, & real-world situations to understand a context with which to then create an example for oneself. This example, will be used to help he/she understand what the original statement was attempting to simplify by abstraction and use of abstract language such as: "problem domain", "characteristics of the class".
I know this is all too philosophical, and perhaps a rant, however I believe that if, and when, I read a section of the book, and I am confused I should comment on it and suggest a possible improvement. I could be confused simply because I don't have a good enough understanding of programming yet, however isn't teaching such individual the point of this Wiki-Book?
Rivanov 17:59, 1 November 2006 (UTC)
replies: text: I agree Rivnov. Its a really dumb example. Yes, of course its technical, but OOP isn't intended to be as abstract as the example indicates. A object that "barks"...all I can say is "what the hell?" Please change it someone, its quite ridiculous. Don't get me wrong, I'm all for abstraction. I'm always looking to keep things abstract and generalizable. But the example takes the abstract properties of OOP way to far so as to make the section confusing to anyone that would be at a level where they'd be interested in reading it. Brentt 02:26, 6 December 2006 (UTC)
thread_title: Fundamental concepts - CONFUSION

message: Someone please change the fundamental concepts section to something that uses a real programming example. The "dog" example is terrible. It will be much easier to understand if you use a example that is dealing with data. Sure maybe you want to keep it general, but every OOP language uses data...so don't use an example that is so general it doesn't include data. Were not trying to explain OOP to gods making animals, we are trying to explain it to would-be programmers that want to learn how to throw data around. Brentt 02:21, 6 December 2006 (UTC)
thread_title: Fundamental Concepts section...ack!

message: It would be helpful to have more users participating in this discussion. Dpbsmith (talk) 03:28, 17 December 2006 (UTC)
thread_title:  [[Wikipedia:Articles for deletion/Aurora (programming language)]]