Talk:Class (object-oriented programming)

Maybe one of you can answer a question that poped into my mind. English isn't my first language so bear with me. When you instantiate a class each instance gets its own set instance fields, but what about methods? Are method definitions copied for each instance? Or are method calls to various instances all looked up from a common definition? And if they are copied for each instance isn't that rather well...wasteful?

---

why abstract classes are used?

Same reason you use interfaces.

---

Wouldn't class (computer science) or class (programming) be better article names? More concise, and hence better... Martin

I would like class (computer science), however pretty much everything here is XXXX in object-oriented programming and I didnt want to get into an edit war over it. Vera Cruz

Sorry. Class (object-oriented progamming) was more correct than Class (computer science) as you could be referring to Windows classes or any many other uses of the the term class not directly connected to OOP. Mintguy

What's a windows class? Never heard of that - the only use of class I've heard in computer science is in relation to OOP... Martin

In the Windows OS a Windows class is a deinition of a type of window. completely unrelated to OOP as Windows is programmed in C and not C++ Mintguy

Fair dos: I typically use MFC, which would explain why I've not heard of it. Martin

If you use MFC you should have come across Windows classes. They are fairly fundamental. Look up WNDCLASS in Help. Mintguy

---

I think the article should be named class (computer science) because

• ordinary people don't know what is an object-oriented programming
• class can be used not just in OO programming but OO design or so on
• class used in windows is not covered by computer science, thus, there is no conflict

-- Taku 18:37 18 May 2003 (UTC)

If they click on object-oriented programming theey will find out what it is. OO programming is the implementation of OO design. Are you saying that the Microsoft Windows Win32 API is NOT covered by Computer science? Mintguy 18:47 18 May 2003 (UTC)

Technically I think so. I mean I am talking about context. If you bought a textbook say compiler used in computer science, I am sure class in the book doesn't mean window class. Besides, window class in windows API is a sense of OOP. Either the title of the article is class (object-oriented programming) or class (computer science), it really doesn't matter. Also, remeber all of articles in wikipedia are for general audience, which means each article need to be written as little as possible technical jagons. Also, OO design is not always implemted by OO programming. It's just a typical case. -- Taku 18:54 18 May 2003 (UTC)

"Because windows API is originally designed as object-oriented way, each window is defined by class called window class. But because computer powers in the time the API was designed are so low, many people claim window class is in reallity not a object-oriented at all."

The above is gramatically incorrect. Please find me a single reference that states that Windows 1.0 or Windows 2.0 or Windows 3.0 were originally designed to be object-oriented. Mintguy 03:36 19 May 2003 (UTC)

I will (give me some moment) but for example, what is your idea about why window class is named as class? -- Taku 03:53 19 May 2003 (UTC)

Because the word class existed in the English language long before anyone thought of OO. Because it means a similar thing to type and because it was a suitable word to use to describe a structure used to type or classify a windowMintguy 04:07 19 May 2003 (UTC)

24 hours have passed So I'm removing the inaccurate sentence. Mintguy 21:34 19 May 2003 (UTC)

Looks we have an edit war starting here. I'll add my two bullets. The Windows API is object oriented. You can do object oriented programming in languages such as C (GTK does it). The Windows class (HWND) has properties (GetWindowText, SetWindowText) and methods (ShowWindow). It is OOP, just not written in an OOP language. CGS 22:11 20 May 2003 (UTC).

ARghhh...... rubbish. HWnd is a handle to a Window. It is not a WNDCLASS. Mintguy 22:33 20 May 2003 (UTC)

Yes HWnd is a pointer to a Window's structure. Like any object reference. WNDCLASS is a pointer to a Window object. All object references (be they structures or classes) are pointers. Handle == internal pointer in the Windows API. CGS 14:56 21 May 2003 (UTC).

WNDCLASS structure is used to create a window. A hWnd isn't a pointer to an object of type WNDCLASS. Even if it was, this still doesn't equate to object-orientation. Once you've create your window you can throw the WNDCLASS away. Mintguy

Needless to say, your definition and CGS's definition of OOP varies. That's all.

My definition? You mean the definition. You still don't seem to have grasped the difference between object-oriented and object based. Mintguy 15:09 21 May 2003 (UTC)

Again you just use your definition, which is not universally accepted. Do you think I and CGS are exceptional people? -- Taku 15:16 21 May 2003 (UTC)

OK Taku if it is not universally accepted please show me a site which states that using objects without inheritance is still object-oriented. Mintguy 15:22 21 May 2003 (UTC)

So that's why I told you give me some moment. I am now doing research about the strict definition of OOP. I will probably rewrite an entirely object-oriented programming article at first. As we see, there is certain confusion related to OOP. Maybe it is because I have a superficial knowledge or some other reasons. Anyhow, it should be worth to discuss this kind of confusion in actual article. What we want to is not either you are right or wrong or I am right or wrong. -- Taku 15:32 21 May 2003 (UTC)

As far as I can see the only confusion is in your head. Wake up and smell the coffee. AFAIK everyone else in the world accepts that objects without inheritance is "object based" like previous incarnations of VB and Delphi etc.. Mintguy 15:40 21 May 2003 (UTC)

Everyone?? I guess except people other you here. -- Taku 16:18 21 May 2003 (UTC)

CGS has made no statment about the use of inheritance. You are the only one suggesting that OOP doesn't require inheritance. Mintguy 16:25 21 May 2003 (UTC)

Taku. From a random page on the web http://www.wamoz.com/js_is_oo.asp "What does object-oriented mean? Indisputably it means possessed of the qualities of an object-oriented programming language. Since the only quality I can find common to all languages touted as object-oriented programming languages (OOPLs) - and unique to languages so touted - is inheritance...."

Another .. http://www.6thcolumn.org/~cue/nyu/java_one/Introduction_LectureNotes_p2.html "Any language that claims to be Object Oriented must have the following characteristics: Classification; Identity; Inheritance; Polymorphism."

and again ... http://msdn.microsoft.com/msdnmag/issues/01/11/Instincts/default.aspx "Inheritance has long been considered by many as one of the most significant design features of object-oriented programming (OOP)."

I can find a million similar examples. And you can't find a single counter-example. Mintguy 16:39 21 May 2003 (UTC)

Because you are searching and I am not spending time for searching yet. Anyway, stop trying to disprove each other. -- Taku 19:09 21 May 2003 (UTC)

Quick google search shows me this article. http://research.microsoft.com/Users/luca/Slides/1996-05%20Class-based%20vs%20Object-based%20Languages%20(PLDI%20Tutorial).pdf. If I missed your point, forgive me. I still don't have much time to look at the termiology or history of OOP. -- Taku 22:33 21 May 2003 (UTC)

And this one: http://sern.ucalgary.ca/courses/SENG/609.03/W98/jyzhu1/review.html

I learned there is a notion that object-based langauges are not good enough classified as OOP but it seems still argued. -- Taku 22:49 21 May 2003 (UTC)

I propose how about the article named Object theory instead of Object-oriented programming? Or we can have two separate articles. -- Taku 22:50 21 May 2003 (UTC)

Taku I take it this is your evidence above. The first one is titled "Object based vs. class based" and it states for object based languages "object generation can be written as procedures but with no real notion of inheritance"- which is EXACTLY the point I'm trying to make. You second link is a DEAD link. Mintguy 02:12 23 May 2003 (UTC)Mintguy 02:06 23 May 2003 (UTC)

See talkpage of inheritance. Sorry about the second dead link, it says (from my cache):

Object-based languages are another form of object-oriented language, in which there is no class and individual objects can be created by some constructs. Some features of the object-oriented languages are also discussed in [Abadi 1996].

-- Taku 02:40 23 May 2003 (UTC)

Taku. There are object-oriented languages without classes see self programming language as an example. But self is object-oriented because it offers up the concept of inheritance and polymorphism. Without these you don't have object-orientedness. To distinguish those languages that have objects as holders of data and/or behaviour but do not offer up features of the OO paradigm the term object based is pretty much universally used. Now it is possible to mimic object-oriented programming features in both procedural and object-based languages, but that doesn't make them object-oriented. Now these are difficult concepts and it is understandable that a few people do not follow the general principle of distinguishing the features of Object-oriented and object based, but the vast majority of the programming world do. I think it only sensible that Wikipedia do the same. We should have an article on object based programming or object theory if you like, but the correct term for the concept that involves OO principles is OO. Mintguy 03:16 23 May 2003 (UTC)

Accuracy disputed

The article contains the statement that "the Microsoft Windows API was originally designed in an object-oriented way". This is inaccurate. The Windows API was designed in 1983 a structured programming way. OOP includes the concept of structured programming but is not the same as structured programming. Rather, it's one implementation and derivative of structured programming. That's probably why some believe it is OOP when it's actually structured proramming. As requested above in previous discussion above, please support the claim of "originally designed" in an object-oriented way, rather than in a structured programming way.

I don't because the situation is dispute over the definition of object-oriented programming. Some agree with me and disagree and some people agree with you and disagree. Wikipedia is not a place to decide which side is right and wrong. -- Taku 03:42, Oct 25, 2003 (UTC)

Do you see the distinction between the concepts of structured programming and object-oriented programming? Do you perceive every use of structured programming to be a use of OOP concepts rather than a use of structured programming concepts? JamesDay 10:28, 25 Oct 2003 (UTC)

---

James Day has asked for my input here, but I'm not sure I can add very much. A few minor things: IIRC, in Win 9x and probably a few others, an HWND is a 16-bit index into an array of internal structures, cast to a 32-bit void pointer for the purposes of obfuscation. A window class has more in common with the English word "class" than the C++ concept. However, the Windows API does have the concept of an "object", which is reasonably similar to the C++ concept. There is a section on it in the SDK. Microsoft went to some pains to categorise objects, and to implement common functions which work on a number of different types of object. At a stretch, this could be called polymorphism.

The Windows API is not what I would call object oriented, and so for the most part I agree with Mintguy not Taku. But I haven't read very much on the matter so I wouldn't know if the definition varies. My understanding of object-oriented programming is where each function is strictly associated with a certain kind of data. Very few if any functions are "global", and the class to which a function belongs is never ambiguous. The Windows API has many "global" functions which are not associated with a class, and the categories Microsoft uses for its functions do not strictly coincide with the type of the first argument passed. -- Tim Starling 11:58, Oct 25, 2003 (UTC)

So you want me to address what I think OOP is so I do. As a concept, OOP is a paradigm that lets programmers to think about programming in terms of objects--those are capable of receiving and sending messages. Each object can be created from a class or a existing object or via other means. To me, inheritance, polymorphism and encapsulation are not essential. They are very useful extensions for OOP programming but the lack of them doesn't make programming competely non-OOP automatically. For example, Object Pascal didn't have access control such as private or public seen in C++ or Java. But it was still designed in the concept of OOP. GTK and GNOME api, for instance perfectly adapt OOP concepts but it is still written in C. The important distinction between structured programming and OOP is that the view how programmers see their programs. OOP language features are not foundamental. Some people assert that OOP is a mere extension where some functions known as methods are bound to a composite type. It is just an implementation choice. OOP doesn't need to be procedural. Procedural programming can adapt OOP but OOP doesn't have to be made in such way. Messages for instance can be executed simultaniously at least conceptually.

Oh, and very importantly, OOP is an idea not a collection of specifications. Something may be not explicitly advertised as OOP but can be seen as having OOP aspects. Think in this way. Hypocraticallt, some language was designed well before the concept of structured programming was introduced but that language adapts aspects of structured programming. Do you claim that language is not structured programming because it was designed before structured programming was known? Or don't think the language has aspects of structued programming? Sometimes formalization of a theory takes some time not mention to its adaptation. Simula is a good example. It was designed before a term OOP was coined but you can see some primitive features of OOP.

This is my POV. And so from this definition, the Windows API is object-oriented. -- Taku 15:52, Oct 25, 2003 (UTC)

I know what you think OOP is, and I honestly don't know if you're right or not. If there are two prevalent definitions, then we should address both in the article, not advocate one of them. If there is only one widely accepted definition, then we should address it alone. Perhaps we need to do more research to determine how many valid definitions there are. -- Tim Starling 06:57, Oct 27, 2003 (UTC)

I disagree that we should address one definition if it is widely known. First, I don't think we can draw a clear line among definitions. Some people are somehow inclined to my side and some are completely far away. Besides, wikipedia is an encyclopedia. Many of articles here are very uncommon. If wikipedia is a textbook, then it is important to sometimes omit certain topics to make a flow. It is not the case in encyclopedia. Maybe we don't have to discuss unpopular definitions in the depth but it must be covered somehow. And if you only include one view, it is called POV.

-- Taku 04:09, Oct 28, 2003 (UTC)

I meant that idiosyncratic definitions shouldn't be included. If 95% of people use one definition, and 5% use the other, then we should include both. -- Tim Starling 04:23, Oct 28, 2003 (UTC)

Of course, but am I the only one who claimed above definition? That is what I have learned, have read at least I believe. Anyway since you are not sure either, I will keep more research. -- Taku 22:02, Oct 28, 2003 (UTC)

Development of OOP

Taku, much of what you want to write would be excellent in an article on the history or evolution of OOP. In that article, it's unlikely to be controversial to write that structured programming and abstract data types were part of the evolution of though which led to the popularity of OOP. They were and I doubt that anyone would disagree. Similarly, in their own articles, a mention of how they were then used as a component of the OOP concept would also be uncotroversial. What is controversial is saying that something which was written before OOP became popular used OOP concepts. That wasn't the frame of mind of those who were doing it at the time. The historical side does need to reflect the views of the time and the views of those who are working on a project if it is a recent project. Otherwise, I could start rewriting OOP articles and say that they are uses of the structured programming or abstract data types concept and remove references to OOP. That would be accurate but it would be misleading because it's not how OOP is thought of by those using it. History of OOP would be an interesting article because it would track the mainstream evolution of programming thought. JamesDay 16:39, 29 Oct 2003 (UTC)

---

Microsoft's own propaganda

In the late 1980's and early 1990's, object-oriented programming was extremely trendy, but then-mainstream programming languages (particularly PASCAL and C) were not object-oriented. It was extremely common for programmers to say that they were writing object-oriented code, or using object-oriented methodology, although they were not writing in an object-oriented language.

All sorts of partially-baked and homegrown ways of achieving this sprung up. For example, C structures might be hidden behind void * pointers, with access provided only by families of accessor and manipulator functions. The resulting thing might be referred to as an "object" and the accessor and manipulator functions as "methods," and so forth and so on. People went crazy writing structures full of function pointers. Almost everything was called an "object" if there was the slightest shred of an excuse for it.

Microsoft "window classes" and message-passing seem to me to belong to this genre.

But when Microsoft was proselytizing Windows in the 1990's, they themselves seemed to take every opportunity to suggest that Windows was object-oriented. The early books emphasized this, said that WIndows message-passing was a form of object-oriented programming, said that the master key to programming in Windows was understanding object-oriented programming concepts, etc. etc.

One of the things I dislike most about Microsoft (and IBM before them) is their habit of mixing marketing advocacy into what should be technical education, and redefining terms to suit their own purposes. But if Microsoft says it often enough to enough people, what they say is the definition of a term does start to gain some legitimacy, whether I like it or not (and I do not).

It's all sort of a grey area and it's a pity that there has to be a flame war about it. When object-oriented languages were not mainstream, there may (or may not) have been some virtue in faking a quasi-O-O approach within the mainstream O-O languages. Today, what's the point in worrying about it? There are enough real object-oriented environments around that anyone who wants to do object-oriented programming and use object-oriented concepts really should be doing it in an object-oriented language.

If we're going to have a flame war, let's have it about something meaningful—like whether a language like C++ can be said to be truly object-oriented when it contains so many fundamental types (ints, etc.) that are not objects and can't be subclassed. Now, that would be fun to argue about.

Well, I've been rambling, but the point I wanted to make is that although IMHO "window classes" are far from being true classes, it was Microsoft, and not just certain Wikipedians, that said they were.

Just my $0.02. Dpbsmith 03:26, 31 Oct 2003 (UTC)

---

Thank you for that interesting explanation Dpbsmith. But I don't understand why everyone's so obsessed with window classes. Window classes are really one of the least classy of the Windows object types. You can't get a handle to them, there's no accessors and there's no hint of polymorphism. Existing classes are accessed either by querying the associated window, or passing the name of the class. As I said previously, if you want OO programming in windows you have to look up the object chapter. I can't find it on the net, so I'll quote some here. This is from a 1996 version of the Win32 SDK. Copyright Microsoft, quoted here for the purposes of academic research.

Windows uses objects and handles to regulate access to system resources for two main reasons. First, the use of objects ensures that developers are not writing code specifically to low-level, internal structures. This enables Microsoft to add or change functionality of the operating system, as long as the original calling conventions are maintained. When subsequent versions of the operating system are released, applications will gain this new functionality with little or no additional development.

Second, the use of objects enables developers to take advantage of Win32 security. Each object has its own access-control list (ACL) that specifies the types of actions processes can perform on the object. The operating system examines an object's ACL each time an application attempts to create a handle to the object. For more information about security, see Security.

For most objects, the Win32 API provides functions that create the object, create an object handle, close the object handle, and destroy the object. These tasks may be combined or unnecessary, depending on the type of object and the situation. For example, an application could create an event object. Other applications could open the event and each would have a unique handle to the same event object. In this scenario, as the applications finish using the object, each closes its handle. When there are no open handles to the event object, the operating system removes the object from memory.

In contrast, an application could obtain the existing window-object handle. In this instance, when the window object is no longer needed, the application must remove the object from memory, which invalidates the window handle.

When a process terminates, the system automatically closes handles and deletes objects created by the process. However, when a thread terminates, the system usually does not close handles or delete objects. The only exceptions are window, hook, window position, and dynamic data exchange (DDE) conversation objects that are deleted when the creating thread terminates.

Handles and objects consume memory. Therefore, to preserve system performance, an application should close handles and delete objects as soon as they are no longer needed. Applications that do not do this can slow the operating system, due to excessive use of the paging file.

Windows provides three categories of objects: user, graphics device interface (GDI), and kernel, as shown in the following tables. The system uses user objects to support window management, GDI objects to support graphics, and kernel objects to support memory management, process execution, and interprocess communications (IPC). For information about creating and using a specific object, refer to the associated overview.

It then goes on to list 31 different objects, and the functions associated with each. The window class is not on the list. -- Tim Starling 00:33, Nov 2, 2003 (UTC)

---

Since the history of the class concept is not discussed here, and since the limitations of the topic or concept are not discussed either, the page is just a rehash of words from other places. 169.207.115.74 23:02, 1 Nov 2003 (UTC)

---

Discussion structure

This discussion is getting too large to read. Isn't it possible to have a short summary and hyperlinked to it the rest of the arguments ?

It is a shame that choice of wordings is hiding more fundamental aspects that I wanted to propose to modify.

I'd like to propose the use of a simpler and more consistent vocabulary (as in Smalltalk).

    Class    is like an abstract datatype.
    Object

    Instance = object       ; inherits from aClass.
    Class defines variables ; = state variable
          defines methods   ; = piece of code = behavior. 

Please do not call methods subprograms. In the Wikipedia class definition, "function" is used. I much prefer that. But I'll agree that we can put functions, subprograms and methods in the same bag for generalists.

This for starters. It would also be nice if the rest of the description would use the same minimal vocabulary in order to have a consistent discource.

I am available for constructure discussions

Cheers --[--René TheJoker Bach 16:33, 5 Nov 2004 (UTC) 16:22, 5 Nov 2004 (UTC)rene@acm.org (background in AI (frames, OO Smalltalk, LISP, Prolog), biology and sailing-racing.

Object-based OOP

I removed this: "Object-based languages with this property do not provide the structural benefits of statically type checked interfaces for objects." Is this true? Also, which property does "this property" refer to? Besides, a class is not necessary a static entity. -- Taku 22:22, May 24, 2005 (UTC)

A lot of pure object-oriented languages rely solely on dynamic dispatch with no type system for objects or static checking of message sends (Smalltalk, Self, etc.). I suppose "this property" refers to this dynamic dispatch, whereas "the structural benefits of statically type checked interfaces for objects" refers to the static type checking you get in languages like C++ and Java. But if this were to go back in I'd also want to add something about the power of dynamic dispatch in encouraging reuse and fast prototyping. Deco 00:05, 25 May 2005 (UTC)

It does follow that if the language allows you to use a data type without defining it then then language compiler/interpreter cannot statically check types. The type check can be done at run-time though, but only from an operational standpoint. Take a read of dynamic dispatch as there is more information there. I'm going to put it back in and try to explain a bit better. — KayEss | talk 01:07, 25 May 2005 (UTC)

I think the problem is this picture: class = static; no-class = dynamic. You can, of course, write a statically typed language like C++ without the use of classes and you can stil get a dynamic untyped languages without classes; especially Ruby comes to mind. Am I missing something? -- Taku 02:29, May 25, 2005 (UTC)

The language that you choose to implement a C++ compiler in is irrelevant as any complete language will do. Maybe you meant implemented in the language? In any case, a language like C++ offers only static typing. That is, the type of any language variable or constant has a single type which can be fully calculated at compile time. A language like VB allows the programmer to use a strict or lax type system. The upshot of this is that the interpreter cannot determine by looking at the source code if a given method invocation is supported by the object at run-time. This in itself wouldn't be enough to label it as an 'object-based' language if it supported other OO constructs (such as inheritance), but it doesn't.

In order to be a full OO system then you must be able to support 1) data encapsulation, 2) method encapsulation 3) dynamic dispatch and 4) inheritance. Languages like VB and JavaScript don't support inheritance so an OO design is much harder to implement in them (but as they are complete languages not of course impossible). — KayEss | talk 03:05, 25 May 2005 (UTC)

I'm sorry for confusion. I was not talking about how to implement compilers. I meant that you can design that languages that do not use classes in the way C++ or Java does. Ruby is a class-based dynamic language. On the other hand, you can also design a statically typed OOP language without classes. Inheritance, for example, can be implemented via prototypes or mix-in. In any case, now I see the problem: we are using a term "object-based language" to refer to different things. I will rewrite the section for general cases when if languages do not have classes. This kind of discussion if it is possible for object-based languages to support OO constructs like inheritance shoud be put in object-based languages. Maybe that it is possible but most of those languages don't. -- Taku 11:21, May 25, 2005 (UTC)

I think your latest edits miss the point. You can put in something about languages that don't use classes, but I think we have to have an explanation of "object-based" as it is a pretty common term. I don't think you can have static typing, OO and no classes. What would your static types be? Even in languages like JavaScript I have written object hierarchies, but there is no language support for them. This is analagous to the situation between C and C++ - the core OO parts of C++ are easy to code in C (generics/templates aren't), but there is no syntactic support in C so it isn't classed as an OO language. The part of the article was defining object-based, not trying to discuss the difference between languages that do or don't have classes. Many object-based languages do have classes (i.e. VB). — KayEss | talk 12:31, 25 May 2005 (UTC)

I changed my mind. I added a short note to refer to class-based OOP for comparision between class-based OOP and non-class-based one. I think this article should be about what is a class and this makes more sense. As for object-based languages, I have a very book at my desk that talks about static object-based languages; languages like Emerald, Cecil and Omega programming language. This remark is telling "The typings associated with prototyp-based languages such as Cecil and Omega strongly restrict the dynamic features, to the point that there is not much difference between those typings and the ones used for class-based languages. Therefore, much of the discussion of types for class-based languages ... applies to statically typed object-based languages." Again, an object-based language is rather vague concept, and defining it is beyond the scope of this article, in my opinion. -- Taku 22:58, May 25, 2005 (UTC)

I'm afraid I don't know any of those languages. What did you do with the text you removed? Did you merge it in anywhere else? I do agree that the article here should be more concerned with classes than object-based systems, but the object-based information here was better than any other I'd come across on the Wikipedia. — KayEss | talk 08:10, 26 May 2005 (UTC)

The same here. I am still reading that book. If I was careful, I didn't delete any stuff. I moved some remarks about the difference between class-based OOP and non-class-based ones to class-based OOP. I think we should talk about how to do programming with classes over there, and this article should cover more of materials like implementations. WIthout C++, you can still perfectly do non-OOP. And, I certainly agree that we need more concrete descriptions of OOP, its concepts and languages. -- Taku 09:00, May 26, 2005 (UTC)

For some reason, Taku keeps deleting the reference to prototype-based programming. Why? Wouter Lievens 09:53, 26 May 2005 (UTC)

I was trying to keep the discussion concise. So my excuse is that in that process, I lost the mention of protype-based programming. I tried to restore this in my last edit. In other words, to answer your question, I was not quite as careful as I wanted to be :) -- Taku 11:17, May 26, 2005 (UTC)

Sub-section on access control?

What about a sub-section dedicated to the access control which is done when defining/dealing with objects? --Mecanismo 15:00, 26 July 2005 (UTC)

Inheritance makes an OO language?

---

Looks like a struct

    Class    is like an abstract datatype.
    Object

    Instance = object       ; inherits from aClass.
    Class defines variables ; = state variable
          defines methods   ; = piece of code = behavior.

From my understanding the only difference between a class and a struct is the fact that classes can have permissions set on the members of itself. C had structs, it is a procederal language. Structs can inherit data from "variables" of the same type which fulfills the defination of inheritance above. Please forgive my spelling its late and i dont really care as long as the message is clear. If this is not how inheritance works then please enlighten everyone.

They are conceptually different. If you just look at keywords like class and struct in C++ then there isn't that much difference between them. From a conceptual point of view though a struct is used to hold data (and some of that data may be function pointers or even functions), whereas a class is a larger concept that includes data and attendant behaviours. In some languages they may be implemented so as to be very similar (like in C++). — KayEss | talk 08:39, 4 August 2005 (UTC)

C structs and C++ structs are very different. Yes, C does not support object-oriented programming, so its structs can't have methods and all that stuff. In C++, structs are almost the same as classes. --Spoon! 02:28, 1 September 2006 (UTC)

Before C++ caught on, however, there was a trend or fad for C programmers to define C structs many of whose members were function pointers. Doing this with the right mindset, defining these structs and their members in the right way, etc. it is possible to do a kind of half-assed object-oriented programming, and in some cases it is actually a worthwhile trick. These people tended to say "we are not using an object-oriented language, but nevertheless we are using an object-oriented approach."

Whether that's a valid point of view, I wouldn't care to say. Having programmed in Smalltalk for a couple of years, it doesn't seem to me that C++ is more than about a three-quarter-assed object-oriented language. It is amazing how often I found reasons to subclass things like integers in Smalltalk, and the inability to do so in C++ is a huge limitation--one which you tend not to notice if you're used to it.

Whether or not language X Truly Has the Object Oriented Nature is one of those areas of semantics and religion that just don't matter to me. Dpbsmith (talk) 12:40, 23 September 2006 (UTC)

Marked as Confusing

I was trying to get a sense of what the introduction of this entry was saying. I really had to dig around to understand it. There is a lot of good information, it just seems like if it was put together a little more elegantly that the knowledge could be conveyed a bit more cleanly and efficiently. --Remi0o 06:14, 20 December 2006 (UTC)

I completely agree. This article has a lot of information, but to beginners (like me), it's overwhelming. There are too many technical terms, and it just ended up making me more confused. Not to say that it should be turned into a "For Dummies" article, but making this article a little easier to read would be a BIG improvement. I think using less technical terms would be a good first. Then if any technical terms are used, they should link to other articles explaining what those terms mean. The examples are great, they should stay. The only real problem with the article is that a technical term should not be explained with another technical term, because it results in an article that only makes sense to someone who wouldn't need to read it! Trin3 19:12, 11 April 2007 (UTC)

Set Theory

It seems to me that there is a strong conceptual link between the idea of a class in OOP and the mathematical idea of a Class (set theory). Classes in OOP can be thought of as a collection of varius kinds of data along with the operations (methods) that are ordinarilly performed on that data. The set theory version of a class is basically the same as far as I can tell. For instance, the real numbers are considered to be a class (where class is the most general name that can be given to the abstract mathematical concept that is real numbers - more specifically they can be considered to be a set, or even a field), and the standard operations such as addition, subtraction, etc. are understood to be associated with the class of real numbers as well. Is it possible that this is where the OOP name for class came from? If so, that might be worth adding to the article somewhere. Juanquij0te 09:48, 7 January 2007 (UTC)

Circular Definitions

The article for "method (computer science)" uses these words: "In object-oriented programming, the term method refers to a piece of code that is exclusively associated either with a class (called class methods, static methods, or factory methods) or with an object (called instance methods)."

In this artcle, classes are described as "a collection of encapsulated instance variables and methods (functions), possibly with implementation of those types together with a constructor function that can be used to create objects of the class."

They both point to each other. This is confusing. Steeltoe 16:07, 11 January 2007 (UTC)

I think this article is wrong because in many languages a class can contain static methods or variables (like C#, Java, not sure about C++) that are not in the field of a specific instance.

I think that instead of going off onto a layman explination of classes in the third or so paragraph of the introduction, a section should be made which introduces OOP and classes to the layman.

-To whoever asked the question. Most methods are within the field of each instance of the class, however there are static methods which are common to that class.

The problem with this type of article is that the exact concepts and terminology used vary from language to language and dexcription to description, and contributors, who are only familiar with an extremely small range of languages (there are thousands!), do not realize that others use the same terms differently. I don't think these articles can afford to provide definitions of concepts from a single point of view, as they can't possibly be neutral that way. Rather they should make differences in the use of terms explicit. Rp (talk) 13:28, 12 February 2008 (UTC)

Examples

I find some of the examples to be either misleading or not very helpful for illustrating the idea of mapping a real world entity to an object in a program, which is one of the real benefits of OO design. For instance the Java example that states "This example shows the simplest Java class possible." is completely false, it shows a simple example sure, but it's not helpful in understanding the point of using a class, and isn't the simplest class you can define in Java:

class Simple {}

Not that this is very simple since an awful lot of behavior is being implied here if you know more about Java. It would be nice if we could come up with some more appropriate examples for illustrating the OO paradigm and the concept of a class, not features of a language or specific syntax. MattOates (Ulti) 12:56, 18 February 2007 (UTC)

Confusing terminology

As a newcomer to the world of C++ programing, I must say the terminology is very confusing and defining said terminology can be done more clearly. Once straightening out what each term means in everyday conversational English, I believe it would definitely clear up a lot of confusion. —The preceding unsigned comment was added by 157.62.105.5 (talk) 19:39, 28 February 2007 (UTC).

Are method definitions copied for each instance?

"Are method definitions copied for each instance?"

No. There is only one definition for each method of a class for all instances of the classes. Only the data (fields) vary by instance.

Jim Anderson

Janderson507 14:24, 29 March 2007 (UTC)

Why abstract classes are used?

"why abstract classes are used?

Same reason you use interfaces. "

---

Actually this is not true. Interfaces provide an API that the consumer must implement, while abstract classes may have default implementations of methods that clients can take advantage of, rather than override.

Jim Anderson

Janderson507 14:28, 29 March 2007 (UTC)

Mutiple Inheritance and Interfaces

"Depending on the language, classes may support multiple inheritance or may require the use of interfaces to extend other classes."

---

This statement doesn't make sense. Interfaces are not required to extend other classes regardless of whether a progamming language supports multiple inheritance.

Jim Anderson

Janderson507 14:33, 29 March 2007 (UTC)

The point is that interfaces are used as a replacement of multiple inheritance in single-inheritance languages. Rp (talk) 13:30, 12 February 2008 (UTC)

Scope

"Scope refers to the visibility of a data component based upon where it is nested, that is between which set of braces ({}) it occurs."

---

Is this statement referring specifically to Java? If so, I think it should state as such. If not, not all programming languages use braces ({}) to delineate scope.

Jim Anderson

Janderson507 14:37, 29 March 2007 (UTC)

Fundamentals of OOP

"This is called encapsulation, and is one of the three fundamentals of object-oriented programming."

---

There are actually four "fundamentals of object-oriented programming." 1. Abstraction 2. Encapsulation 3. Inheritance 4. Polymorphism

Jim Anderson

Janderson507 14:41, 29 March 2007 (UTC)

"Unlike multiple inheritance where actual code is inherited (along with naming and logical conflicts), interfacing allows us to define a behavior interface (methods) all implementing classes should be able to fulfill."

---

This statement doesn't make sense. Whether or not code is inherited has no relation to the number of supertypes (single or multiple inheritance). Multiple inheritance can be implemented with interfaces, in which case, no implementation code is inherited.

Jim Anderson

Janderson507 14:54, 29 March 2007 (UTC)

"The methods that are not in any of the interfaces of a class are private to the class, and not intended to be depended on by other classes."

---

This is not necessarily true. A sub-class may choose to extend it's parent with public methods not included in any inherited interface.

Jim Anderson

Janderson507 14:59, 29 March 2007 (UTC)

This article and its discontents

This article is far from the standard I expect in a Wikipedia article. I am new to programming and I wanted a clear and lucid encyclopedia definition of the concept of a class in OOP; instead I get something that reads like it comes from the manuals that fail to explain it clearly in the first place, while the discussion page contains very little serious effort towards improving the article, being taken up instead by a fight about Microsoft. Beginning programmers like me are very aware of the huge gap between doofus-level programming books, which are easily mastered and usually overwritten, and the more useful stuff which is pitched far above our heads. Wikipedia is in a position to fill that gap by explaining subjects as clearly as possible without a lot of whimsical cruft, but this article doesn't do it. I would make suggestions to improve it, but I only know about writing comprehensible English, very little about the subject in question. The only helpful suggestion I've seen is the tentative analogy between classes in OOP and classes in set theory; I don't even know if it's a good analogy, but if so it at least helps to make things clearer. (The article on Pointers strikes me by comparison as a model of how to write this sort of piece.) Can we stop the 'edit war' (which isn't one, because very little editing seems to be getting done) and get on with explaining the topic, please? Lexo 14:19, 5 May 2007 (UTC)

is content sufficiently general?

just a quick observation based only on a quick skim:

contributors to this article may want to be careful that assertions and examples apply to all OOP environments rather than just a subset.

for example, i think i noticed an assertion that objects based on classes need to be instsntiated which impies that classes are not objects, which might hold true for C++ but not for smalltalk in which everything is an object including classes IIRC (my reason for looking up this article in the first place was that i'm getting a bit rusty on this stuff... and frankly didn't find the article all that helpfull.)

given the title of the article the content strikes me as a bit narrowly focused and overly detailed. not sure if that's a problem with the content or the title. -ef

Mistake in pseudo code ?

referring to the inconsistent use of the semicolon (;) in the Introduction section. —Preceding unsigned comment added by 62.101.126.216 (talk) 01:48, 25 September 2007 (UTC)