Talk:Object-oriented programming

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / CompSci (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computer science (marked as Top-importance).
 

Find sources: "object-oriented" – news · newspapers · books · scholar · JSTOR · free images

"Decoupling"[edit]

The term "decoupling" is vague, and has a buzzword feel to it. Attempts to objectively measure it have been problematic or depends on many unproven assumptions. I'd suggest not mentioning it. --66.120.226.84 (talk) 18:30, 24 October 2008 (UTC)

I don't think the term is vague at all, though I think the article currently does a terrible job of explaining what it is (namely, elimination of inter-object dependencies by use of encapsulation/information hiding/interface rigor). Nevertheless, neither "decoupling" nor "instance" is among the "quarks" listed in Armstrong's original (2003) paper submitted for publication, which is available free online at [[1]] (retrieved as reference number ITRI-WP034-0303). The version published in 2006 is available from the ACM at [[2]], but you have to be a member (I'm not). Unless the published version added "instance" and "decoupling", they should be deleted from the article. -- Unconventional (talk) 19:10, 14 November 2008 (UTC)
I suggest either finding a good clean formal definition along with a wiki article, or not mention at all. Doing it half-way is confusing to the reader, who will already be burdened with lingo. --63.192.29.10 (talk) 16:01, 10 May 2010 (UTC)

I'm reading and I don't understand it. The following sentence can be read in two different ways: "Decoupling allows for the separation of object interactions from classes and inheritance into distinct layers of abstraction." I'd be grateful if someone who understands it could rewrite it. —Preceding unsigned comment added by 141.108.15.99 (talk) 10:36, 15 February 2011 (UTC)


Up until this section, the article was making some sense to me. I agree that some change is required, but have no idea what change. Jonathan G. G. Lewis 10:42, 5 November 2013 (UTC) — Preceding unsigned comment added by Jonazo (talkcontribs)

"Design Patterns"[edit]

Should we be listing the 23 patterns here, given that there's a Dedicated Wikipedia article on the book? Gerardw (talk) 12:22, 19 December 2008 (UTC)

I've read the entire "Design Patterns" section twice now and I still don't really understand what its about and what it has to do with design patterns. Given that most (all?) design patterns have relevance outside of OOP, I think its probably best just to have a link to the Design patterns page unless the content is truly OOP specific. --Kragen2uk (talk) 23:08, 12 January 2011 (UTC)

"Misleading sentence"[edit]

"In the 1980s, there were a few attempts to design processor architectures which included hardware support for objects in memory but these were not successful. Examples include the Intel iAPX 432 and the Linn Smart Rekursiv."

"Not successful" is misleading here, the fact that the iAPX 432 was slow or Rekursiv not successful commercially doesn't mean that they not were succeseful implemting OO in the MMU. —Preceding unsigned comment added by 200.127.136.93 (talk) 02:17, 6 January 2009 (UTC)


Section "criticism" needs expansion[edit]

Would very much like to see the section "criticism" expanded to at least a couple of paragraphs. I am not at all competent to this myself. -- 201.37.230.43 (talk) 14:09, 21 February 2009 (UTC)

I agree with you that it needs expansion. Instead of destructive criticisms, rants or laconical criticisms that do not help the reader to assess the benefits and limitations of OO technology, what I would like in that section is published, referenced examples of specific, well-delimited problems where a "pure" OO solution would be inherently more complex, harder to understand or harder to evolve than a solution to the same specific problem using another technology (say, DSLs, functional programming or even cell-oriented programming like in Microsoft Excel).
Now this would be a nice contribution to improve the article so that it provides a better overview of the characteristics, advantages and limitations of OOP. --Antonielly (talk) 16:56, 21 February 2009 (UTC)

The current criticism section reads in a petty and personal way. It doesn't read like an encyclopedia should at all. --M2tM (talk) —Preceding unsigned comment added by 207.47.201.6 (talk) 00:51, 4 August 2009 (UTC)

It seems to me that anyone who dares to criticise OOP (or wonder what all the fuss is about), is seen as unknowledgable/reactionary/ petty or similar. If you actually care to look at the experience and stature of these critics you will see that this is not the case. As a programmer myself, with more than 40 years experience (and many successful products), I actually believe that conventional programming is far more efficient, faster and does not involve largely undefinable terminology and "get arounds"/"fudges". It is suspicious, to say the least, that nobody has yet provided a recognizable generic definition of OOP or provided proven benefits. I have spoken with several well respected programmers who, like me, have yet to accept any of the so-called "benefits" of OOP. Sadly it's another example of "The Emperor's New Clothes" that has simply got out of hand in a massive way. — Preceding unsigned comment added by 81.157.169.126 (talkcontribs) 11:19, 7 August 2009 (UTC)
In the same way that you normalize relational databases you can normalize objects to move their state closer and closer to the behavior that utilizes it. This is the benefit of true object oriented programming when used correctly. You get logical containers or 'tools' that are specfic behaviors married to their state. This allows stability through immutability. Other programmers using these stateful/encapsulated objects can trust that they will behave the same no matter who else is utilizing that object within the program. In contrast procedural or data driven programming like i've often seen used in VB6 or COBOL programs the driver program maintains the state and governs over mutability and the classes merely have behavior. You pass state into the behavior and you you get back a modified state or you get back a result or condition of whether or not your behavior succeeded. All of which your driver program must maintain. The benefit of procedural program is one of 'visibility' into state management and less 'delegation' as you can read the driver program as one document of events happening. My only citation is my experience of 13 years in software development. The enlightened software developer knows when to employ OOP or procedural or SOA or any new paradigm as it comes about. Only zealots use one and speak against the others. —Preceding unsigned comment added by 69.76.159.241 (talk) 20:25, 21 March 2010 (UTC)
"It is suspicious, to say the least, that nobody has yet provided a recognizable generic definition of OOP or provided proven benefits."
The same can be said about cults. Are you equally suspicious about the effectiveness of cults? Kidding aside, this is called a continuum, in the real world(OOD), continuum exist. — Preceding unsigned comment added by 72.187.199.192 (talk) 22:44, 20 November 2010 (UTC)

"Static programming languages"?[edit]

The criticism section implies that OO is a feature of "static programming languages" as opposed to Lisp.

Object orientism requires no specific language feature other than the ability to encapsulate or 'black box' state within a container and expose behavior to external containers.
  • I can't find the term "static programming language" in the literature. Is this phrase supposed to refer to "statically-typed programming languages" (e.g. C++), as opposed to "dynamically-typed programming languages" (e.g. Lisp)?
  • If so, why is OOP exclusively associated with statically-typed languages, when there are so many OO or multiparadigm dynamically-typed languages (e.g. Objective C, Python, Ruby, etc.)?

I am not knowledgeable enough about Lisp (or OO design, for that matter) to rewrite this section. Could someone clarify, or at least add some references? --Otterfan (talk) 23:36, 16 March 2009 (UTC)

Wait, I get it--"static programming languages" isn't a commonly-used term, but it appears that "dynamic programming languages" is. Still, there seem to be a lot of object oriented dynamic programming languages. This still needs clarification, or at least some references. --68.239.60.5 (talk) 04:11, 19 March 2009 (UTC)

I'm no expert on langauge definitions, but I understood the term 'static language' to be as above - ie not a dynamic language (such as lisp) (aside comment eg maybe compiling to a contiguous machine code without any list structure connecting 'bytecode' as might be found in a dynamic language)
I definately didn't think it refered to static/dynamic typing.
If that's the issue maybe a note type reference would be a good idea - clarifying what is meant by 'static programming language' ?
Or was the issue whether or not the statement(s) is(are) true?83.100.250.79 (talk) 22:38, 26 June 2009 (UTC)

Object vs Instance[edit]

These are the exact same thing. That should be explicit. —Preceding unsigned comment added by 81.252.207.82 (talk) 13:43, 20 March 2009 (UTC)

No. This is the same only in the language that support classes. P99am (talk) 11:57, 24 April 2009 (UTC)

Fundamental concepts[edit]

Fundamental concept of Object Oriented paradigm is object, not a class. Define objects as the implementation/exemplar/instance of a class is not correct. This is a purely technical definition in some languages (supporting classes). Object Oriented Programming is not equals Class Oriented Programming.

I agree that classes are not fundamental to Object Oriented programming. A well-known example is Javascript, which does not have classes. Also, the meta-analysis on wikipedia is basically inclusive, so it includes various concepts that are disputed. There exists (I have read it), a meta-analysis research paper which compares a bunch of OOP systems and concludes that the only concept that is universal and fundamental to all OOP systems is that of objects having identity (as opposed to being values). I wanted to add this with the reference, as I believe it has great practical and theoretical significance to the topic, yet this idea isn't mentioned in the article. Unfortunately I can't find the paper. Does anyone know of this paper? IIRC it was an IBM research paper. There are various other papers that mention it as a core concept, but this paper was the strongest. — Preceding unsigned comment added by 124.120.204.38 (talk) 15:43, 29 January 2013 (UTC)

Section Fundamental concepts turns everything upside down.--P99am (talk) 11:57, 24 April 2009 (UTC)

Physical existence of an "object" - is it unecessary baggage? - can occams razor help?[edit]

Try as I might, I have not yet come across any instance (definition) of what an object is - in physical terms. I understand that OOP defines objects in some physical sense (rather than a virtual data definition) but I have yet to come across an actual example of how this manifests itself internally in the OOP language. I think I have seen these objects in an 'exported' sense - with seemingly long strings of (comma separated?) text attributes - but what of its internal representation? For example -

  • how large is a (typical) object definition (in bytes)?,
  • does it have an inherent or implied structure or OOP standard? (and is this portable?),
  • who decides what attributes it holds and in what (optimized?) form?,
  • how much data is involved when accessing an object?
  • how much processing is involved in decoding the object at execution time?

Since conventional programs can (and do) perform the same tasks as any OOP written program - without the need for any physical objects - this seems to imply that the physical objects themselves are a case of unecessary 'baggage' (requiring additional processing themselves). Using occams razor therefore, these pieces of baggage can therefore be safely removed and a more optimum solution used to provide algorithmic efficiency. This optimum solution, I would suggest, is the much simplified "conventional" programming paradigm that grew up around the first computers - unsurprisingly - as the most 'natural' way to program them.

If someone has a real life example of how an object manifests itself physically (in a particular language) perhaps they would be good enough to highlight a simple example of it here for everyone to compare with a conventional solution. It would be useful to answer the questions above in relation to their example also. If the example is good enough to serve as a generic illustration, of an OOP object perhaps they might also include it into the article itself to educate all of us? It would also be nice if the example refrained from the much overused animal metaphores and restricted itself to more real-life scenarios such as simple addition of two values (unless of course you think I am 'barking up the wrong tree' or just simply barking!) ken (talk) 11:11, 21 August 2009 (UTC) Two weeks have passed since my post above. No sign yet of a response! Isn't there anyone who can defend the OOP 'paradigm' with a concrete example of what constitutes an object in reality (at least in one language) and then go on to explain the mechanics of how this is superior to a more conventional imperative programming approach using a real life example. Since I posted the above, the thought occurs to me that such a physical object must, of necessity, be an object itself - leading to a "vicious" infinite regression of objects, each describing themselves. See also my comments in Talk: Object(computer science) Can we implement OO in any language?!!ken (talk) 09:33, 5 September 2009 (UTC).

Nobody replied because it's not worth replying to. See the banner at the top of this talk page? This discussion page is meant strictly to improve this article. Wikipedia is not a forum for debating hot topics. Do you have some concrete improvement to propose? Pcap ping 10:57, 5 September 2009 (UTC)

I would have thought that an example of what an 'object' is, is quite central to the concept of object-oriented programming. If nobody can provide one it is, to say the least, quite peculiar. Presumably if you are so confident that there is no improvement that can be made to the article, you can either provide a link to what I am asking for on some other published site or can point to the place in the existing article that answers my question.ken (talk) 15:05, 6 September 2009 (UTC)

Where does this article discuss the "physical existence" that you debate? I'm unable to find it... Pcap ping 15:52, 6 September 2009 (UTC)

That is precisely the point! The article linked to in the introduction (i.e. object (computer science)) describes the OO concept of "'physically' bringing together the data components with the procedures that manipulate them". In any case, it would be difficult to see how an (OO) object could have any reality without this being the case (essentially being a combined data description and a function pointer). However, how this exactly is implemented is not shown by example - in any language in either article - despite the fact that (OO) objects obviously can be manipulated independently of the underlying 'target' object (the data) and therefore must have some physical existence. —Preceding unsigned comment added by Kdakin (talkcontribs) 19:07, 6 September 2009 (UTC) Two weeks later! On my tedious search for an answer to my question, I came across this java topic [3]which seems to at least confirm my belief that OOP objects do indeed have a physical existence. If they have a length in bytes they surely must contain something! The obvious question, which I am still short of an answer to is, precisely what? It reminds me of the question "How long is a piece of string" - at least I now know it has a length - now please what is the string made of? (and please no flippant answers like green cheese or quantum soup or quarks!) ken (talk) 09:19, 21 September 2009 (UTC)

Its data members, and a vptr, is one possible answer. But these are implementation details, and not really important to such an abstract topic as this. Regards, decltype (talk) 09:49, 21 September 2009 (UTC)

Sorry Decltype, but I think telling me that there are pointers (rather obviously!) embedded within 'objects' is not the answer I am looking for. I also believed that objects pointed to 'data members' and did not actually contain them. Why do you think this is an 'abstract topic' and not a real one? The whole point of the question is to ask why there appears to be no example of what EXACTLY an object is - when implemented (and incidentally - how much memory and processing overhead this represents). To explain it by saying it is 'abstract' and just an 'implementation detail', is avoiding the very relevant question of precisely that. If you don't actually personally KNOW the answer (from the experience of a compiler writer for instance), why bother to attempt a 'possible' answer?ken (talk) 18:13, 21 September 2009 (UTC)

That's not so obvious to me. An object need not contain any pointers, and most certainly not a vptr. However, this is one common way of implementing virtual functions (which some would say are vital to OOP), and causes an overhead the size of a pointer. However, as the vtable article (hopefully!) tells you, this is just one possible way of implementing late binding. Now, in most C++ implementations, there will be no overhead except for the vptr (in the presence of virtual functions), and the caveat that even an object of class type with no member subobjects must occupy at least one byte (with one exception). Apart from that, the objects contain their base class(es), and their member subobjects, and not pointers, unless the member subobjects are themselves pointers. However, even the simplest class may (or may not) contain unnamed padding. Most compilers allow you to manually adjust alignment. Thus, the object layout can be completely different even for two executables created from the same source code with the same compiler, and the answer to the question of how much memory overhead there is for each object remains the same: It is entirely up to the implementation. Regards, decltype (talk) 06:25, 22 September 2009 (UTC)

Thank you Decltype, I am now (ever so slowly) getting a beakdown of an 'object'

So, now I know that:-

  1. objects are at least one byte long (except in one case apparently)
    true, but this is very C++-specific. The exception is the Empty base class optimization. The fact that not even I have bothered to create an article on it yet, indicates that it's not that significant.
  2. objects may have automatic, or manually specified, padding
    Yes. The article seems to give a good overview, so no additional comments
  3. objects 'contain' their base class(es), and their member subobjects, (- whatever that implies? ) and not pointers
    Member subobject = data member.

I also strongly suspect (but do not know for sure) that:-

  1. they have a physical name (in the form of a character string equal to its string length) - not mentioned by you
    No, this would be incredibly wasteful. Type identification can be facilitated for instance by examining the vptr.
  2. most objects have pointers to at least one method (multiple methods implying multiple pointers)
    Typically, member functions are implemented like normal functions, except that a pointer to the object ("this") is passed as a hidden argument to the function.
  3. not all methods are virtual functions - fair enough
    This is certainly not true for other languages. In many OO languages (such as Java), methods are "virtual" by default.
  4. different implementations imply different 'object' structures (- which I would venture is a little inconsistent for an entire new paradigm!)
  5. the actual implementation of an 'object' is not itself derived using OOP mechanisms for the 'objects' datastructure

I also suspect that:-

  1. the attributes of an 'object' are held within the object in one form or another - not mentioned by you
    I'm not sure what attributes you are referring to, but a conforming implementation need not put anything but the raw data of the data members (+ base class instances) inside an object.
  2. 'subobjects' are chained from base classes (and to one another) by some pointer mechanism - not mentioned by you
    No.
  3. objects require 'creation' and usually 'initialization' before being used - not mentioned by you
    I didn't realize you were asking about this, but sure, see constructor.

I am, in fact, only asking for a breakdown of ONE implementation so that I (and others using wikipedia) can see 'what makes OOP tick' at its basic level. Just one example of the Data structure of a couple of 'objects' (in their entirity) complete with names, init. & method pointers and object attributes would suffice, along with a narrative of how the objects are created, processed (and destroyed?) in a typical scenario like adding two integers together. This does not have to be in hexadecimal, Pseudocode will be good enough to get a rough idea of the sizes of data and processes involved.ken (talk) 07:06, 23 September 2009 (UTC)

I am going to break the normal conventions of the talk page to address your points individually. Unless otherwise noted, my answer holds true for most common C++ implementations, but may be blatantly wrong for other programming languages. decltype (talk) 07:28, 23 September 2009 (UTC)

The more I learn about OOP, the more I realize that even its protagonists appear not to understand it sufficiently to give a clear and concise definition of what it is. Here [4] is a link to the OOP article in wikibooks that is about as clear as mud. Why is it so difficult to show a simple example of precisely how the memory is mapped for adding two values together? Let me make it easy for someone and put my wish into the form of a question perhaps set at GCE 'O' level.

Q.There are two 32 bit integers in contiguous memory locations A and B. The integers were read in together from some external I/O device as a single record and some general register points to the start of the record as the program is given control. It is required that the program adds the two input values together and passes the resultant value as a return. Draw a diagram to show the necessary memory 'blocks' used by the program and describe each step in the process using pseudocode (show ALL your workings). Do this for a conventional program and an OOP program.

6 months later and still nobody has responded to the challenge! Meanwhile I discover myself some more of the hidden awkward truths behind OOP implementations - heap storage used to create new "objects", calls to constructors to initialize them and heap storage used for message passing - containing (largely unecessary) exact copies of parameters; "getters" and "setters" instead of direct assignments; serialization/marshalling - breaking both so called encapsulation and data hiding. Return values provided from sent messages (instead of waiting for a result message in response) - making a mockery of the concept of true message passing. More getarounds than rats in a maze. Proprietory data mappers to automate multiple conversions between object and binary formats. Free format human readable character text strings of data and attributes used to describe data objects externally. Discussions about whether binary XML solves the newly created data compression problem or not. Parsing, parsing and yet more parsing seems to be all the rage these days. The abstraction penalty - written large - is, it seems, most evident in OOP. When will it all end - and sanity once again prevail? —Preceding unsigned comment added by 86.142.16.251 (talk) 11:14, 21 April 2010 (UTC)

okay, I'll byte.. or at least take a nibble at this  ;-) You are thinking much too low level and perhaps paradoxically, not low level enough. vptr is a good answer to your original question, you just (appear to) lack the background to be able to understand the answer, perhaps a better answer would be to tell you that it's "42". The high level understanding is that an object is a private name-space referenced by a public interface. What an object does is that it groups together zero or more data items, and provides standard methods for accessing and modifying that data. The relationship of the data items to each other and to the world is defined by the object itself via zero or more associated program routines (usually) called methods. Everything else is an implementation detail and is totally language specific. The bottom line is that an object encapsulates things that the programmer has decided are useful to be packaged together, the end goal is to manage both memory and complexity. To ask questions about the storage size of an object is to display a complete lack of understanding of computer programming (obviously the size is data+overhead). --- (hey ken, I looked at your talk page, youre not ignorant, so I guess you are flame-baiting?) --- Which then brings up the question of who is this article written for? If it is intended to be useful to non-programmers than considerably more explanation is needed. But if that were done I suspect the article would be encumbered to such an extent that it was no longer of interest to programmers.... codeslinger_compsalot 67.40.8.215 (talk) 08:39, 9 December 2010 (UTC)

Thanks for trying 67.40.8.215, but I don't think you address the issues that I have raised, dismissing them as "implementation detail". Why shouldn't I (and everyone else) know the implementation detail for heavens sake? If I was engineering Formula 1 cars I would be extremely interested in the implementation details of my competitors cars (and also for reasons of curiosity and knowledge building).
It is only by having implementation details that will allow serious comparisons of two or more "methods" (techniques). Implementation details are available for most other entities in the real world, why ignore/censor them for OOP?
I have recently read a humorous blog "Execution in the Kingdom of Nouns" by Steve Yegge(see here) that encapsulates a lot of the problems with OOP - even at the conceptual level (although he doesn't go nearly far enough imho!) let alone the implementation.ken (talk) 10:29, 31 December 2010 (UTC)

I'll be brief since this is off topic for a talk page, but I think you are confusing a paradigm with an implementation. I realized this today as I was talking with a co-worker who has some similar objections. When someone is talking about OOP, they are talking about a system for organizing data and processing and associating them together. This can be done in an object oriented language or any other language. The level of detail you are concerned about is the implementation. The reason nobody can answer you is that OOP design can be implemented any of a large number of different ways. A particular language may implement it with waste and overhead in storage to support other compiler optimizations, but an OOP design could be implemented in assembly if you really wanted to. In the example of taking two fields that come in next to each other, it could be as simple as setting up an object that encapsulates them and has a function pointer to add the values at the offsets. Perhaps no OO language would implement it that cleanly, but at that point you are comparing RAD to compilers to machine code instead of paradigms.Ajh16 (talk) 16:38, 22 April 2011 (UTC)

In a pure OO implementation (no unboxed numbers) you'd need some primitive i/o routine that reads the integer values from memory:

Integer add_two_words(Address loc) {
   Integer a, b;
   a = read_int32_from_loc(loc);
   b = read_int32_from_loc(loc+4);
   return a+b;
}

The above isn't actual Java, it's OO pseudocode that I used the java template for. 69.111.194.167 (talk) 03:20, 26 April 2011 (UTC)

Regarding "implementation details" and how important or otherwise they are, see Whitaker et al. "Software engineering is not enough" ken (talk) 06:02, 6 August 2011 (UTC)

Formal def issues[edit]

Here's why I tagged those bullets:

Pcap ping 17:44, 26 August 2009 (UTC)

Pointers are routines?[edit]

How so? Is this about pointers to functions? If so it needs some rewriting. Pcap ping 19:23, 26 August 2009 (UTC)

OOP with ANSI-C[edit]

"ANSI-C is a full-scale object-oriented language" Object-Oriented Programming With ANSI-C by AT Schreiner - 1993

It would be nice to have a section on OOP techniques in non-OOP languages.

Removed external link to a Richard Mansfield article[edit]

I have removed an external link to a purported whitepaper by Richard Mansfield titled "Has OOP Failed?". It seems to be little more than a subjective rant; the author refers to computer science as "computer 'science'," claims that most programmers prefer non-object-oriented languages without citing a single source, etc. dpol (talk) 22:31, 14 March 2010 (UTC)

Mr. Mansfield has been in the industry quite a while and has been involved in many publications. This qualifies him as an experienced industry observer. There is not a lot of direct evidence on the benefits of OOP either way such that if you turn up the scrutiny knob, the entire article may end up disappearing. --63.192.29.10 (talk) 16:07, 10 May 2010 (UTC)

With regard to the question of whether OOP has failed or succeeded, I think someone should investigate whether vb.net (a pure OOP language) is more successful today than VB6 (not a pure OOP language) was in its day. Also, it might be worth clarifying the definition of success and failure. —Preceding unsigned comment added by 2.96.55.14 (talk) 18:30, 13 March 2011 (UTC)

I agree, Mr. Mansfield's criticisms aren't very constructive or insightful, and I'm hardly a fan of OOP. The link to his article in the "Criticism" section should be removed. The other OOP criticisms are well made, but the one by Mr. Mansfield is very weak and poorly defended. I also don't get why he thinks OOP is a darling of academia, either. Maybe in 1980 it was, but it certainly isn't right now. A far more useful critique of OOP comes from Oleg Kiselyov. (see http://okmij.org/ftp/Computation/Subtyping/) — Preceding unsigned comment added by 76.90.217.240 (talk) 22:37, 20 October 2011 (UTC)

I just looked and the quote is back. I agree that ads no value and I'm going to remove it MadScientistX11 (talk) 15:06, 10 December 2013 (UTC)

Abstraction is also achieved through Composition[edit]

Abstraction section says "Abstraction is also achieved through Composition". Could we get a source? All references on internet seem to come from wikipedia.

Try searching for "inheritance vs composition". 69.111.194.167 (talk) 02:01, 26 April 2011 (UTC)

Section "criticism" needs contraction[edit]

As of 2010, I think we have a little perspective about what criticisms of OOP proved to be valid or at least insightful, keep those and drop the rest. Otherwise what we have here is a List of failed predictions regarding object-oriented programming patsw (talk) 18:04, 20 July 2010 (UTC)

Agree absolutely MadScientistX11 (talk) 15:00, 10 December 2013 (UTC)

well, I use oop a lot, I find it a very useful technique. But I also am aware that it has a fad like nature, in the sense that it has been very much over hyped (cough cough ruby). I find the anti-opp quotes to be refreshing, illuminating, and humorous. It makes for a great counter-balance to a subject that is often lopsided. My vote is to keep the quotes. I'm a programmer who been at it for about 30 years. 67.40.8.215 (talk) 07:40, 9 December 2010 (UTC)

Wikipedia is an encyclopedia not a blog. The purpose of the articles is to inform not amuse or to include things that people find "refreshing". I agree with Patsw those quotes are out of data and in many cases now just flat out wrong. One of the references talks about how OO can't support strong typing which is obviously false. MadScientistX11 (talk) 15:00, 10 December 2013 (UTC)

Section History[edit]

Hi, When I was reading about the two commercial products, it struck me that there was only one example given. I think that is not in line with the objectivity of Wikipedia. Moreover, this example - which I do think is a beautiful characteristic of VB.NET framework - can be put into more perspective of the principles of Object Oriented Programming, which is the subject of this article. This cross-language inheritance is an interesting way to abstract code from implementation using the Strategy pattern. Java does have a similar feature, the virtual machines, which is abstracting the code from the implementation as well, but now using the Adapter pattern. So I thought I could enrich the example provided, extend it with another example from the commercial world thereby raising the objectivity of this article using just three sentences. I do hope one approves. Loekbergman (talk) 06:23, 27 July 2010 (UTC)

Overview[edit]

Hope I'm not stepping on anyone's toes, but it seemed that a very simple-to-understand intro at the start of the Overview was in order so I added in several very simple paragraphs there. Unsure as to how much material to cover there; any suggestions? Warraqeen (talk) 18:44, 12 December 2010 (UTC)

Also, I've moved the pre-existing paragraph in the Overview which starts "A large number of software engineers agree..." into the Criticisms section. I'm not really sure it's necessary at all, but I thought it was safer to move it than delete it. Obviously a Criticisms section is important (OOP has many critics and many alternatives), but the paragraph I'm referring to seems to me not to say much more than 'some are for it; some are against it' which didn't need stating in an overview, in my mind. Warraqeen (talk) 10:42, 30 December 2010 (UTC)

Technical Template[edit]

I see that somebody has added a technical template to the article, but I have not seen anybody offer an explanation in the talk section for why it is there. OOP is a fairly complicated subject which I don't really believe anybody would be trying to learn specific details of without enough background in programming to be able to understand or quickly research the technical terms in the article. Looking at what the template says should be done, it says to simplify things as much as possible without losing truthful accuracy to the information and that simple information as a general overview should be toward the beginning of the article. There's a nice concise definition at the beginning and then an expansive and fairly non-technical overview written almost wholly in common vocabulary. Unless we want to rewrite the entire article as lame analogies, I'm failing to see anyway to put it in laymen's terms moreso than it already is. Going into specifics beyond the overview doesn't seem to be possible in less technical terms than are already used and the subjects which might require further reading provide links to the appropriate articles. So does anybody care to explain how this article is too technical?98.27.162.44 (talk) 02:23, 13 December 2010 (UTC)

Agreed! I am unable to imagine how to "improve this article to make it understandable to non-experts", so I think this template should be removed!--Tim32 (talk) 21:34, 13 March 2011 (UTC)

Using OOP to Simulate the Real World[edit]

"Criticism"?[edit]

The so called criticism section seems weird to me, trying to concoct a conflict pro or con object orientation. The real questions instead seems to be how much? and when?, and any answer and opinion must explain in what PL, with which object implementation and what OOA methodology. F.ex. the article by Luca Cardelli pinpoints some good and some bad qualities of OOP:s and ideas about how to circumvent the bad sides. Potok, Vouk and Rindos instead pinpoints that the reuse of code provided by OOP:s is discouraged by organisational structures within large corporations.

I think the section is valid and contains usable material providing reflection over advantages and disadvantages of object orientation, but not specifically "criticism". At least some of the sources provided produce an analysis of the productivity improvements, or lack thereof. This is more like neutral "evaluation", and so the section shouldn't describe the authors as having "criticized OOP". Rursus dixit. (mbork3!) 20:12, 2 April 2011 (UTC)

"Criticism" refers to both positive and negative feedback. The current title is too wordy. I will use a title that makes the full meaning clear.
Fennasnogothrim (talk) 08:08, 30 April 2011 (UTC)
I agree. The criticism section made sense ten or even five years ago but now it should be titled "The Academics who don't know much about developing software in the real world and made fools of themselves" section. This debate is over guys, OO won, it's the default for new systems in just about every industry and most kinds of applications. And except for Stahlman most of the people quoted don't actually know much about real software development. I think that section should be removed or greatly reduced. MadScientistX11 (talk) 00:57, 10 December 2013 (UTC)

Actually the problem is the term "objectoriented" by itself: Without doubts are functions in Javascript and even structs in C objects. The only thing what they don't have is inheritence. Which is a great thing, but only if it's used correctly (and that needs a lot programming experience!). So we should slowly forget about this term "objectoriented" for languages with inheritance and see what's real. Even more, "objectoriented" programmers often include controller-code into the objects, which is a violation of MVC...so I fully understand the critics in this article (but only after more than a decade of "OO" programming). 178.197.236.172 (talk) 15:33, 24 July 2013 (UTC) "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle"...lol, that just reminds me of nowadays Java frameworks. 178.197.236.172 (talk) 15:43, 24 July 2013 (UTC)

Structs in C and Javascript are absolutely unequivocally NOT object-oriented. Saying it's "object-oriented but without inheritance" is like saying my girl friend is a beautiful woman except she has a penis (that was hypothetical btw). There actually is a word for languages like Javascript (Ada as well although they may have added true OO to Ada by now but at least in the version I was familiar with a few years ago) those are called Object Based, you can define objects which are essentially Abstract Data Types but they don't have inheritance or polymorphism. Sturcts in C though don't even qualify as object based. I've never heard anyone say that. Of course you can define various processes and utilities that build some OO capabilities on top of structs in C or in any language but by that metric assembler and COBOL and any language is OO, it's all a Turing Machine after all. MadScientistX11 (talk) 14:55, 10 December 2013 (UTC)

Overview is misleading[edit]

The overview seems to confuse OO with modularity and encapsulation. Although this is a common mistake by beginners, who tend to extrapolate from a small exposure to different languages, we should aim for more precision. In addition there is plenty of weaseling about. Other things like run-time checking of data is by no means typical of OO. Reusability has been a goal of many software technologies, and it's far from clear that OO is any more successful than others.

Perhaps the overview should just be discarded, and a summary of the current situation could be added to the history section, which I think is much better? — Preceding unsigned comment added by Ketil (talkcontribs) 13:15, 28 April 2011 (UTC)

I'm not a beginner and I think OO absolutely IS all about encapsulation and modularity. If it's not about that what is it about? MadScientistX11 (talk) 01:00, 10 December 2013 (UTC)

"Comarea"?[edit]

A few days ago 86.142.127.235 changed a sentence to read "With designs of this sort, it is common for some of the program's data to be accessible from any part of the program (sometimes grouped into what is often known as a "Comarea").". The paranthetical section referring to "Comarea" is, IMO, nonsensical as this is not a common usage at all. In fact, the only time such a thing comes up on a Google search (e.g. for "program +comarea" or "programming +comarea") is a small number of references to IBM and HP mainframes, almost entirely when dealing with CICS. 86.142.127.235 has also recently modified some CICS related articles, so I'm assuming this editor spends their time engrossed in this niche community, rather than the computer science or programming community at large. I am reverting this part of the edit, unless anyone has any objections. -- Menacer (talk) —Preceding undated comment added 00:08, 2 August 2011 (UTC).

Now restored with some modifications. Google search is not definitive and many terms were in use 30 years before PC's were in existence. IBM 360 Assembler (1960's) had a "COM" area addressable via a system parameter. CICS was (is?) the most common transaction processor worldwide. Programs in commercial use were (are?) significant in terms of global trade/importance and are hardly "niche". Engrossed is a massive exageration for editing just two articles.ken (talk) 14:56, 14 August 2011 (UTC)

Copyvio[edit]

This edit reeks of a copy-paste. It is the user's only contribution. It's clear from copying any part of the edit into google that the exact same text exists on multiple separate websites. This text has since been edited with wiki markup and integrated into the opening section of the article, but the point remains that the text itself is duplicated elsewhere.

I do not know exactly what to do about this, as my knowledge of copyright violation on Wikipedia is limited. I did not use the copyvio template because, to my knowledge, that involves blanking an entire page. It is unlikely that the text on the other websites was copied from Wikipedia, as the original contribution is significantly different from the prevalent style of Wikipedia.

At the very least, the section needs to be edited to reword everything and to conform to current style guidelines. The simplest solution is to delete the text, but I'd rather have an editor with a more thorough understanding of copyvio policies take a look at it. 67.193.178.107 (talk) 07:45, 24 January 2012 (UTC)

Agreed, gone. Sorry about that, I should have caught it when it was added. Andy Dingley (talk) 10:29, 24 January 2012 (UTC)

Why is there no "benefits" section?[edit]

The article gives a long list of arguments not to use OO programming techniques. But OO must have benefits other than than it is perhaps "fashionable" or "modern".

FWIW I think that OO programming allows more elegant programs that are (potentially) easier to debug - at the expense of a considerably longer learning curve. Learning an "ordinary" computer languages typically is a matter of weeks, while writing truly OO programs (not just programs that dutiful apply OO constructs) requires the experience of months of even years.

I leave it to the (real) experts) to describe the (claimed) benefits of OO programming in a more precise (but hopefully still concise) way. Rbakels (talk) 07:28, 23 April 2012 (UTC)

Ok. The fact is that OOP is very elegant programming for GUI--Tim32 (talk) 14:35, 24 April 2012 (UTC)

Restating the Definition of OOP[edit]

Hey I'm a student at NJIT. I am doing this for my Technical Communications class. I was reading the definition that is presented at the top of the article and I feel that it lacks some clarity. I think the definition is stated well enough for people with some background in programming and the Object Oriented paradigm but since wikipedia is supposed to be a place where the general population can come to learn the basics about a topic I feel that The definition should be rewritten to facilitate this. Another Problem with this definition is that it has not been cited with a source (scholarly or otherwise). I think adding a source would enhance this page as well.

My proposed definition is as follows. Changes I have made to the definition based on my gathered information is displayed in bold.

Object-oriented programming (OOP) is a programming paradigm that represents concepts as "objects" that have data fields(attributes which describe the object) and associated procedures known as methods. Objects which are instances of classes are used to interact with one another to design applications and computer programs.

I took out the information regarding techniques associated with OOP from the definition because I do not not believe it enhances the definition. That sort of information can be put in other areas of the article so that the reader does not become overwhelmed with information in the introduction. The reader can build his/her knowledge base up by reading the article so that when these topics appear in the article he/she can have a better grasp of what they actually are.

The source I found that corroborates this information is: Kindler, E., & Krivy,I. (2011) Object-oriented simulation of systems with sophisticated control. International Journal of General Systems,40(3),313-343. Doi:10.1080/03081079.2010.539975


If anyone has any thoughts or opinions on my proposed changes please feel free to comment. — Preceding unsigned comment added by IKP2-NJITWILL (talkcontribs) 00:18, 22 November 2012 (UTC)

I disagree with the change. Object-oriented paradigm doesn't represents only concepts. I will prefer to use more general terms like "real-world things" or "subjects domain". Also when it says that represents concepts, I would avoid mention of terms like "data field", "methods", and "classes" because these are how the paradigm is implemented in concrete languages, but not the definition of the paradigm. The paradigm wants to represents objects of the real-world, encapsulating its attributes and behavior, and interacting with each other.
--Klodr (talk) 02:20, 26 December 2012 (UTC)

Who was the first OOP language?[edit]

Right now this article makes two contradictory claims:

Used for simulating system behavior in the late 1960s, SIMULA was the first object-oriented language. In the 1970s, Xerox's Smalltalk was the first object-oriented programming language

There can only be one first one. --SingpolymaT E 21:00, 11 December 2012 (UTC)

I agree this section is crying out for some informed editing. The comments about the development of OOP languages belong in the History section, and should be reconciled with the existing content already there, and the duplicated content in other sections should be eliminated. Jonathan G. G. Lewis 10:57, 5 November 2013 (UTC) — Preceding unsigned comment added by Jonazo (talkcontribs)

Actually, I don't think this is a contradiction. The text says Simula was the first OO language and Smalltalk was the first OO Programming language. Simula was not a general purpose programming language, it was a language specifically designed for developing simulations. Simula definitely came before Smalltalk though. I've heard Allen Kay say that and since he was one of the creators of Smalltalk... MadScientistX11 (talk) 00:41, 10 December 2013 (UTC)

new major section needed[edit]

"Design Patterns" should not include "Object-orientation and databases" and the following sub-sectinos — Preceding unsigned comment added by 68.183.23.147 (talk) 20:12, 16 January 2013 (UTC)

There are patterns for integrating OO and RDBs. So I'm not sure what your point is. --MadScientistX11 (talk) 16:15, 11 December 2013 (UTC)

Gang of Four design patterns - Main article: Design pattern (computer science)[edit]

The "Main Article" is about more than the gang of four - it lists many more patterns than seen here — Preceding unsigned comment added by 68.183.23.147 (talk) 22:31, 16 January 2013 (UTC)

History does not include mention of CLU or Barbara Liskov[edit]

Why is there no mention of the CLU language or Barbara Liskov in the history section? Her work has been recognized as important to the development of object oriented programming.Dllahr (talk) 23:38, 29 January 2013 (UTC)

"Code gallery" section[edit]

Removed completely misleading and bogus non-example of OOP from the so called "Code gallery" section. It was a complete mess, the only member of the "gallery", written in an unspecified language, doing unspecified things in a manner foreign to OOP. Whatever unspecified purpose it might have had, the code was perfectly capable of crippling anyone's grasp at OOP for a considerable amount of learning time. Until a less harmful example is found, I think the article is better off without it for the time being.

Two main branches of OOP?[edit]

Apparently there's an Alan C. Kay concept of OOP and a Barbara Liskov concept of OOP, and they don't mix on a fundamental level.

Kay OOP is about isolated machines sending messages to each other (Smalltalk). Liskov OOP is data-oriented encapsulation (C++).

Liskov said she was not aware of Smalltalk until 1975, and that development of CLU had started at about the same time as Smalltalk.

Alan C. Kay coined the term object-oriented programming (OOP) and he "did not have C++ in mind." C++ is Liskov OOP, not Kay OOP.

Sources: Barbara Liskov, Keynote, OOPSLA'09, 24th ACM SIGPLAN http://www.youtube.com/watch?v=qAKrMdUycb8

Alan C. Kay http://en.wikipedia.org/wiki/Alan_Kay

Liskov OOP vs Kay OOP https://news.ycombinator.com/item?id=2336444

Moryton (talk) 06:56, 24 July 2013 (UTC)

There aren't two branches of OOP there are lots of them. Or at least there were. In the early days you had people from AI, software engineering, formal methods, etc. I think these "X vs. Y" fights (e.g. Booch vs. Rumbahgh, C++ vs. CLOS,...) were always mostly silly. They were part ego and part hype from vendors who made outrageous claims because that unfortunately is what you often need to do to sell some new software. I looked at that last link you provided and it seemed mostly to be people saying "Kay said X" on a discussion board which isn't a valid reference IMO. I've heard Allen talk about C++, his main issue with it (which a lot of us had) is that it's an OO layer on top of a low level procedural language and it still left a lot of the gunk like pointers available for people to use and cause problems. Anyway, I would strongly urge us to stay away from these religious arguments, X vs. Y, they are for the most part of historical interest at this point anyway, I suggest we focus on concrete issues: benefits, costs, etc. MadScientistX11 (talk) 14:45, 10 December 2013 (UTC)

References to NOOP...(self promotion?)[edit]

Hi. I've been reading a few articles on OOP, coupling, cohesion, etc., and all over the place I find references to a recent book (NOOP, by AbdelGawad). Furthermore, these references in the text claim that "the author of XXX proved YYY", leaving very little room for doubt and suggesting that whoever added that to the wikipedia article read and confirmed that those proofs are correct, or that they are widely acknowledged as correct.

I see that all modifications to these references (on several pages) were made on the same day, within a few minutes, from the same IP. As far as I've been able to check, it's an IP in Egypt, were the author of the very same book is from (haven't checked the city, haven't been able to link the IP to a university or institution).

I think this is reason to suggest that this might be a case of self promotion or modification by a person involved with the author (co-worker, student, etc.), which would make that reference and information probably biased and, if I remember correctly, against wikipedia rules.

Could somebody else take a look and confirm whether these suspicions may be correct?

--2001:610:1908:1200:6C87:7C1:6CA2:BEF5 (talk) 15:21, 30 July 2013 (UTC)

I took a look, and it seems like a pretty clear-cut case of citation spamming to me. I removed the ones I could find - if you see more, please remove them as well. Thanks! - MrOllie (talk) 15:40, 30 July 2013 (UTC)

LOOPS?[edit]

In the "History" section there is a hyper link for "LOOPS (programing language)". This page does not exist, it should be "LOOP (programing language)". The language itself is called LOOP so the word and the hyperlink should both be changed

I just fixed this. Made the red link point to the actual article. From the article I'm not convinced that the link makes sense anyway, LOOP seems like a pure functional language not an OO language, the two are quite different, but I'm not going to address that for now, at least the red link is gone and the link points to the intended subject. RedDog (talk) 16:11, 11 November 2013 (UTC)
I think this is supposed to be a link to an article on LOOPS, an OO extension to Lisp that was part of the Xerox tooklkit, I think on their Lisp machines. It looks like there was an article on LOOPS at one point, or perhaps there was always just a red link, anyway there is no article now although I think one would be merited. It definitely shouldn't be to LOOP which is a functional not OO programming language. MadScientistX11 (talk) 01:10, 10 December 2013 (UTC)
I changed this and replaced "LOOP" with "LOOPS" but with no (red) link. MadScientistX11 (talk) 14:36, 10 December 2013 (UTC)

Examples[edit]

Okay, this one isn't a biggie, but does anyone think namng Objective-C as the first example, without even mentioning C++ is a little... Weird? I mean.. come on. — Preceding unsigned comment added by 31.25.23.102 (talk) 11:31, 15 August 2013 (UTC)

Lisp is not OO[edit]

Currently the article says: "Languages with most of the features of objects (classes, methods, inheritance, reusability), but in a distinctly original form" and includes Lisp as such a language. Common Lisp had none of this except reusability which pretty much every language strives to deliver. There were lots of extensions to Lisp (e.g. Flavors, CLOS) that were OO but the base language definitely was not. I'm going to change this. MadScientistX11 (talk) 00:47, 10 December 2013 (UTC)

I just noticed this is said in the History section as well, claiming that Common Lisp is an object-oriented language. Common Lisp WITH CLOS is an OO language but common Lisp or most Lisp dialects are FUNCTIONAL programming languages not OO. I'm going to change the history section to take out the claim that Lisp (without CLOS) is OO. MadScientistX11 (talk) 18:06, 11 December 2013 (UTC)

What's Missing from This Article IMO[edit]

I used to be a consultant specializing in helping large IT organizations start using OO methods and tools. For what it's worth I had a way of introducing the ideas of OO that usually went over very well. This is one of those things you hear someone else say and you pick it up and make it your own, in my case I got this from an ex boss who was a lead scientist at Bell Labs and MCC before being my boss. What he and later I would always say to the programmers who had been doing it for 20 years and didn't want to change was the following: "Look there is a lot of BS and hype around OO. The vendors and gurus will pretend it's the mythical "silver bullet" that all of us who have read Brooks know really doesn't exist. So, no it's not magic and it's not going to suddenly revolutionize everything and make software trivial to develop and maintain. In fact what it REALLY is is just an extension of the good design principles you guys have been using all along. If you look at the progress of IT it starts with spaghetti code then moves to structured code then to abstract data types with structured code. OO just takes that idea to the next step. An Object is essentially just an abstract data type and the methods are just the functions that would be defined on an ADT. All the rest are bells and whistles to make things a bit more manageable and to incorporate good ideas and best practices we've learned over the years but the fundamental idea is an EVOLUTION and in fact a natural evolution from the good practices you've been using and not some drastic revolution." Curios what others think, I guess I'm slightly guilty of starting a general discussion but from my read of the article maybe a little abstract discussion is worthwhile, I think there is a lot of good stuff in the current article but it doesn't flow well and needs serious work in some places. I might try doing some of that at some point, I'm working on other things that I think will generate less controversy (and are easier to fix) right now. So I was wondering what people thought of the above idea. MadScientistX11 (talk) 14:33, 10 December 2013 (UTC)

I rewrote the Overview section with this viewpoint in mind, used several classic software engineering and OO references: Booch, Meyer, Books, etc. --MadScientistX11 (talk) 16:12, 11 December 2013 (UTC)

FUNDAMENTALS OF OBJECT ORIENTED PROGRAMMING AND ITS BASIC PROPERTIES[edit]

WRITE THE FUNDAMENTALS OF OBJECT ORIENTED PROGRAMMING DESCRIBE ITS BASIC PROPERTIES? — Preceding unsigned comment added by 1.38.23.41 (talk) 08:31, 21 February 2014 (UTC)

"MIT trying to steal OO ??"[edit]

I think most programmers agree that SIMULA from norway is the first OO language / model. Indeed the MIT examples show OO constructs, and I will argue that almost ANY language by the 80's was converging to this.

So the MIT paragraph at the beginning is not relevant and misleading. I vote to remove it. — Preceding unsigned comment added by 24.17.241.173 (talk) 18:46, 22 March 2014 (UTC)

Stepanov interview[edit]

From http://www.stlport.org/resources/StepanovUSA.html (for possible use in article):

Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work: Bill Gosper's Hakmem is one of the best things for a programmer to read. AI might not have had a serious foundation, but it produced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, together with Guy Steele). I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

70.36.142.114 (talk) 00:49, 21 April 2014 (UTC)

Not commenting on your opinion of OOP, but you are categorically wrong about mathematics and axioms. You start with axioms. If you don't, you don't have any mathematics. Proofs do not precede axioms and axioms are not produced by proofs.