Can a good samaritan programmer or not explain once and for all for the benefit of dummies like me what OO means in a clear explanation? And what is the benefit of OO languages. 

It's about time we all knew! 

(Note: TopMind did NOT create this topic nor write the above.)

See also ObjectOrientationTips
----

I'll try. Object oriented programming is one of many ways to organize source code. Instead of defining data structures and the methods that operate on them separately and hoping they will be used correctly, object oriented source code explicitly groups them together. Object oriented programming languages have syntax that enables this grouping. This grouping is called "encapsulation" (but see EncapsulationForDummies).

    // Potrzebie encapsulates a veeblefetzer, some halavah and the frammistan with a method to farshimmelt them.
    class Potrzebie {
        Veeblefetzer aVeeblefetzer;
        Halavah someHalavah;
        Frammistan theFrammistan;

        farshimmelt() {...}
    }

Programmers create templates that describe how data and methods will be grouped, called "classes". Specific instances of the data based on these templates are called "objects". Each object obeys the rules defined in its class. Think of classes as sets (like the set of all horses) and objects as members of sets (like Mr. Ed, a member of the set of all horses).

    Potrzebie myFavoritePotrzebie = new Potrzebie();
One class can reuse the definition of another class and add or modify some aspects of it. This is called "inheritance". That term came from biology, but it doesn't map well to it. Think of it more as specialization.

    // W''''''ickedPotrzebie adds the notion of wickedness to Potrzebie.
    // It also redefines farshimmeltization to take wickedness into account.
    class W''''''ickedPotrzebie extends Potrzebie {
        int wickednessLevel=23

        farshimmelt() {...}
    }
It's often useful to call the same method (or send the same message, depending on your terminology) to different kinds of objects and have them behave differently. That's called "polymorphism".

    Potrzebie myLeastFavoritePotrzebie = new W''''''ickedPotrzebie();
    // Now we have 2 Potrzebies, one more wicked than the other.
    // We can send them the same message and get different results.
    myFavoritePotrzebie.farshimmelt();
    myLeastFavoritePotrzebie.farshimmelt();
There are several benefits to object oriented programming. By encapsulating data structures and methods a programmer can help ensure that the data structures are used correctly. He can hide the messy details of how something works (implementation) from what the rest of the system sees (interface). He can make a promise to the rest of the system that the interface will be stable but keep the freedom to change the implementation in the future. By inheriting from an existing class he can reuse its code and data in a specialized class. Polymorphism reduces the amount of code a programmer has to write to make sure the right method gets called for the right data because the language promises to figure that out behind the scenes.

Does that help?

-- EricHodges

----

''Could we modify this just a bit? I'd offer the following alternative language: Object oriented programming is one way to '''write programs'''. Instead of defining data structures and the methods that operate on them separately and hoping they will be used correctly, object oriented programs explicitly group data structures and procedures together, while guarding access to data structures from "outside" procedures. Object oriented programming languages have syntax that enables this grouping. This grouping is called "encapsulation".''

I thought of that when I wrote it, but decided against it. Programs are what source code defines. Organizing "programs" could mean where I put them in a directory structure, where I deploy them, how I categorize them, how they interact, etc. Source code is what programs are made of, and it's really source code that we organize with object oriented programming techniques. Or so it seems to me.

''I changed "organize" to "write", does that help? By the way, the addition I care most about is the provision of blocking access to data structures from outside the class - to me, this is a fundamental aspect of "encapsulation". Meanwhile, I like "program" more than "source code" because object-oriented code can be generated or otherwise manipulated so that it has no "source code". I guess that mainly I think its important to avoid the impression that "Object Oriented" is some high-level language construct that a compiler gets rid of during code generation. Smalltalk and Java byte codes are just as object-oriented as the source that creates them. I think it's REALLY important that developers understand how to recognize and step through OO code at the executable level inside a debugger or trace it in a log.''

Some OO languages don't block access to data structures. Some OO languages (like C++) block access to data structures but they leave holes that allow data structures to be misused. I call blocking access to data structures "data hiding" and keep it distinct in my mind from encapsulation. That's why I was purposefully vague when I later said "a programmer '''can help ensure''' that the data structures are used correctly". In many OO languages the help is just a suggestion, not a mandate.

''While I agree with you about the shortcomings of the way various OO languages support encapsulation, nevertheless the term "encapsulation" means to both separate interface from implementation and prevent outside code from modifying state. For example, the hits from a Google search with the querystring "encapsulation object oriented" are typified by statements like:''

	 :	''Most object-oriented programming languages support data abstraction by preventing an object from being manipulated except via its defined external operations. In most languages, however, the introduction of inheritance severely compromises the benefits of '''this encapsulation'''."'' (http://citeseer.nj.nec.com/snyder86encapsulation.html, emphasis mine)

	 :	''Hiding details and providing common interfaces is called encapsulation, which is an analogy from making an object look like it's covered by a capsule (the interface in this case). This allows two objects differing in internal representation but having the common interface interchangeably usable (called interchangeability). Interfaces also allow to facilitate the use of data structure and '''guard the state of the object from invalid inputs and modification of the structure'''.'' (http://en2.wikipedia.org/wiki/Encapsulation, emphasis mine)

	 :	''In object-oriented programming the concept of encapsulation is used to create abstract datatypes that should be possible to modify only through their external interface.'' (http://www.lirmm.fr/~ardourel/WEAR/wear03Skoglund.pdf)

** SmallTalk and other "scriptish" languages would be excluded if that was the case. The idea that OOP is largely about locks (GateKeeper) is questionable, or at least needs a more rigorous vetting.

** ''That's a baffling response.  I don't see how SmallTalk is "scriptish". (What, by the way, '''is''' "scriptish"???) I don't see how being "scriptish" (along with SmallTalk, apparently) has anything to do with it.  I don't see how you've interpreted, from the above, that the writer wants you to think that OOP "is largely about locks (GateKeeper)".  Have you perhaps put your response in the wrong place, intending to reply to something else?''

** I was responding to: "...the term "encapsulation" means to both separate interface from implementation and ''prevent'' outside code from modifying state." (Emphasis added). As far as the classification of SmallTalk, perhaps I should have used a different term. But the point here is that it does not prevent "direct" manipulation of attributes outside of the methods and is generally considered "OOP". In fact, it was created by the guy who coined the term.
** Now I will agree that OOP may "shape" the code protection schemes used in a language, but that's different than being a requirement of OOP. In other words, there's a difference between saying "OOP requires..." and "OOP languages tend to protect direct attribute access by...".
** Related: EncapsulationDefinition, EncapsulationIsNotInformationHiding

** ''You appear not to have responded to my post.  Again, what is "scriptish"?  How is SmallTalk "scriptish"?  What does being "scriptish" have to do with encapsulation?  What makes you think encapsulation is about "locks"?  Encapsulation is about separating private implementation details from public interfaces, not "locks".  Encapsulation is based on the same fundamental idea that lets you change gears in your car without risking getting your hand mangled by the cogs or burnt by oil.  Encapsulation is based on the same idea that lets you can call your mum on your cell phone without knowing how PCS, GSM, CDMA and TDMA work.  And so on.  Encapsulation is about hiding the messy mechanical internal details from the outside world.''

** I only mentioned "scriptish" to suggest that "dynamic" OOP languages often lack the ability to have a "hard wall" (GateKeeper) between class user and its "guts". It was a statement of industry tendencies, not about a rigorous definition. It's not the primary issue of my argument anyhow. (We can work on re-wording that later.) Such languages don't keep your hands out of the gears, to use your analogy. They rely on convention, programmer discipline, and documentation to avoid "improper" fiddling with the guts[1]. (Some say they lack TypeSafety.) If you claim "hard walls" are necessary to be "OOP", then we have a problem, Houston, for reasons already given.

** ''Did I claim that "'hard walls' are necessary to be 'OOP'"?  I took issue with precisely the things that I wrote about.  Please correct them, and feel free to delete this discussion when you have done so.  By the way, encapsulation is about identification; it is not necessarily protection.  Note that I wrote that it's "based on the same fundamental '''idea''' that lets you change gears in your car without risking getting your hand mangled", not that encapsulation necessarily prevents -- in OO -- getting your (virtual) hand (digitally) mangled.''

** It clearly reads to me like you are. And the "change gears without getting hands mangled in the cogs" analogy appears to reinforce the original statement. Maybe I'm reading them differently than you intended, but it appears clearly to be about solid walls and protection to me (as far as physical descriptions of a virtual world can be taken). One can swap the gear mechanism yet keeping the same shifter handle, I would note, but the "guts" may still be exposed. 3rd opinion anyone on the protection issue as worded? And "identification" needs some clarification. -t

** ''My "change gears without getting hands mangled in the cogs" analogy was primarily intended to illustrate the distinction between interface (the gear shift lever) and implementation (a box of cogs) in a resonant and visual manner, but the allusion to "solid walls and protection" is not undesirable -- many OO environments combine encapsulation with data hiding.  However, that does '''not''' mean data hiding, aka "hard walls", are essential to being OOP.''

** Okay, but based on the nature/title of this topic, it should stick to the basics in my opinion and not go into ''side'' topics, such as "protection", other than perhaps provide brief suggestions and links for "further reading". I agree that one can build protection around OOP's constructs, but that is neither an essential nor primary characteristic of OOP (by most assessments).

''The last citation, "A Survey of the Usage of Encapsulation in Object-Oriented Programming", seems directly relevant to our discussion and is quite recent (22 July 2003). I'd ask, again, if you'd consider rephrasing your description of "encapsulation". To me, it leaves the impression that encapsulation is about grouping code and data, when its industry usage is more about separating interface from implementation and managing data access.''

Nope, I'm sticking with FOLDOC on this one:

''"In object-oriented programming, the technique of keeping together data structures and the methods (procedures) which act on them."''

Lots of folks confuse encapsulation with data hiding, but I won't.

''I don't think its "confusion", at best you (and apparently "FOLDOC") are instead associating an unusual meaning with a commonly used term. I've added a pointer for those who care. -- TomStambaugh''

''I think the term FOLDOC was talking about is "Abstraction". It's different from "Encapsulation". If you check the citations in EncapsulationForDummies, I think you'll end up concluding (like me) that the FOLDOC definition is simply mistaken. In your paragraph, if you replace "encapsulation" with "abstraction", you at least don't send the "dummies" down an incorrect path. You might then also mention that separating implementation from interface (and managing access to code and data along the way) is called "encapsulation". -- TomStambaugh''

I consider generated code to be source code. I consider executable UML diagrams to be source code. They are both the source for a compiler or interpreter. The fact that Java bytecodes are object oriented isn't very important to novices. I'm not even sure it's important to anyone. The fact that there's a virtual machine that knows about objects between our code and the silicon is an implementation detail.

What I wanted to convey to novices was that object oriented programming is really about how we organize source code. We can put methods and data structures in one big lump, we can put methods and data structures in two separate lumps, or we make a bunch of little lumps that have some methods and data structures in each. If you look at the source code for the same program written in different paradigms you'll see the important parts (the parts that solve the problem) in each of them. The big difference (to me) is how they are organized. When I was a novice that view helped me apply my procedural programming skills.

''I would point out that OO is not the only way to organize code. Non-OO paradigms or methodologies do not necessarily lack organization or a grouping approach, just a different philosophy behind the organization. Which approaches are better is the subject of endless HolyWar''''''s.''

That's why I said OO is "one way" to organize code, not "the best way". I'll change it to "one of many".

It is perhaps to be noted that OOP does not necessarily result in faster programs. The advantage, when obtained, is in code that is easier to implement, easier to understand, and therefore easier to maintain. OOP makes some things clearer than procedural programming did. It makes some things faster and some thing slower when it comes to execution time.

''"Clearer" is not a very clear metric. My procedural programs are not "less organized". They follow "best practices" I have gained over the years. They are not randomly organized. "More organized" implies that OO's competition has more randomness in it than OO. I would invite you to clarify. They may be "differently" organized than OO, but they are not "less" organized by any known metric.''

I said OOP makes some things clearer than procedural programming. For instance, in a procedural program it is common to have methods that interact with a common data structure. Let's consider a linked list. There will be a data structure for linked list elements. There will be a procedure for adding elements to a list. There will be a procedure for removing elements from a list. There may be a procedure for initializing a list. The procedural paradigm offers no way to indicate that these methods are related. The object oriented paradigm does. They methods and data structures can be encapsulated in a linked list class. This makes the organization more clear when reading and maintaing the code. OOP offers all of the organizational power of procedural plus the ability to associate methods with data structures. Although this can, in theory, be done in a procedural language, the language structures of an OOP language make it easy and natural.

Re: '''The procedural paradigm offers no way to indicate that these methods are related.'''

''Put them together in a module or "include" file. That is plenty to indicate they are "related". I don't use linked lists that often anyhow these days. (Maybe other niches like low-level systems programming may.) As far as OO being a "super-set" of procedural, I kind of doubt that because many OO languages don't have functions, and need at least an extra dot-item to emulate them. Plus, I don't think it makes sense to load every paradigm into a language and/or application.''

But modules and include files aren't part of the procedural paradigm. They are only aspects of certain procedural languages. Linked lists are just an example. The same organization can be applied to any part of a system at any scale. Every OO language I've ever seen has procedures. The "extra dot-item" doesn't change that fact.

''What definition of "procedural" are you using? I don't think anybody uses a "bare minimum" procedural implementation except maybe tiny embedded devices. It would be like comparing OO using only prototype-based OO languages instead of those with direct inheritance. Even if a language had no concept of "module", one can still physically group functions together and put some sort of thick comment around them to make it clear they are related. Procedural does not inherently dictate how functions are physically grouped or not grouped. Ideally they should stored in a relational database in my opinion so how they are "grouped" is purely relative to however you want to see them. The limits you talk of are because flat files, an archaic technology, shapes the thinking of computer scientists too much. In other words, don't hard-wire any kind of sorting or grouping such that one is stuck with the authors' grouping. See CodeAvoidance. If you had a pre-condition, such as "if you are stuck with flat files, then OO provides better grouping", that might be more acceptable (although text grouping is usually always a compromise). Even Microsoft is moving toward relational file systems. In my opinion, OO is solving problems based on 1970's technology. But now we are growing more practical options over one-dimensional text.''

They are only aspects of certain procedural languages. Linked lists are just an example. The same organization can be applied to any part of a system at any scale.

''In practice I can and do group "related" functions. However, if using flat files, one is often forced to choose between an action-oriented grouping or a noun-oriented grouping. You cannot have both. OO tends toward the second, which is a '''compromise'''. There is no one "right" grouping in one-dimensional text.''

Every OO language I've ever seen has procedures. The "extra dot-item" doesn't change that fact.

''Java has no global functions. Otherwise, I could do "print(x)" instead of "system.out.Print(x)".''

''Also, having procedures still doesn't change the fact that grouping by entity (noun) and grouping by activity force a compromise in the flat-file world. OOP doesn't "fix" that trade-off.''

----
Oh, this looks like fun. I'll give it a go. So far, we have a definition that talks about language features and a definition that talks about structure. I'll see if I can give it a different spin...

Object-oriented programming (OOP) is a style of programming, like procedural programming or functional programming. For some programs, OOP allows you to create a GoodDesign more easily than procedural or functional programming does.

* Example? Since this is a training topic, such would be expected.

Object-oriented programming, as a style of programming, can be done in a number of languages, not just object-oriented languages. It's possible to do it in procedural languages like C and it's also possible to do it in a database using stored procedures. Similarly, using an object-oriented language doesn't mean you're using object-oriented programming; many programs have been written in a procedural style in an OO language.

Why OOP? Because, for some programs, OOP results in a better design. The downside is that GoodDesign with OOP is harder and requires more training than the other mainstream style, procedural programming.

OOP enables better design (for some programs) because its fundamental organizing unit is an "object:" a collection of "instance" data with "methods" that operate on the data. Well-designed objects hide instance data behind methods, thus allowing unrelated parts of the program to deal with the same data without duplicating common logic. This enables several key components of GoodDesign: DontRepeatYourself, decoupling, and cohesion.

* ''Example of necessary duplication in non-OO? (And please, not another case-statement debate here.)''

OOP also allows you to create designs that reflect your domain experts' view of the world. This is called DomainDrivenDesign. DomainDrivenDesign enables GoodDesign because allows new developers to come up to speed more quickly because and it makes the correctness of the code more obvious. It makes the correctness of the code more obvious because developers can talk with the domain experts about the exact structure of the system rather than performing a mental translation between the experts' statements and the code. That reduces translation errors.

* ''In my experience, different people model the world differently in their head. Besides, the design is for software maintainers, not end-users. OO is rarely defined as a UI technique.''

There are cases when OOP results in a better design than procedural and vice-versa. I can't define the boundaries exactly because there's too much subjective judgement involved. OOP is probably more appropriate than a procedural style if the program has a lot of use cases utilizing the same data in similar ways. It also indicated when there are complicated rules about how data interacts and the tool used to manage the data can't enforce the rules easily.

-- JimShore
----
An ObjectOriented perspective to me is very natural. We can get intimidated by the mechanics of it - encapsulation, polymorphism, inheritance etc but looking at it with BeginnersMind: even a baby knows they are objects in the world. Blocks, toys, tables, chairs. These things have features - attributes such as size, shape, color, texture. Things happen to objects - they get moved, opened, closed, created, destroyed (or "mashed" if you ar a 2 year old). A sailboat goes in water, wind blows and catches it's sails and it takes a path in the water. These are events in time and the way the object responds - it's "nature", are determined by it's Methods. For programmers, objects can be abstract entities such as BillingCycle not just physical things but for each class of objects the associated attributes and methods are defined same as for physical entities, and interactions (or messages) between objects determine the behaviour of a larger system.
Children can also understand classes - they know that this object is an "animal" as opposed to "plant" and that certain items of gourmet are DinnerFood as opposed to SnackFood. Combining classes is much like joining lego blocks together. If you see the value of looking at the world this way then it makes sense to do some work to understand the more detailed mechanics of programming using OO. Before I learned OO I had difficulty dealing with multiple files with hundreds of functions each for large projects. The effort needed to learn details of OO was well worth being able to better organize systems. 

''But entities with attributes can be found in databases also. In the real world actions and things acting on them are often not associated with a single noun. See PrimaryNoun. That is artificial to me. A splash caused by throwing soap into the water is a product of both the soap and the water (plus velocity). In the real world actions and nouns tend to have a many-to-many relationship. I agree with the naturalness of the attribute part of it, but not the behavioral part. I don't get OO's alleged benefits when it comes to behavior.''

UnifiedModelingLanguage also I think is helpful, not to follow legalistically but as a tool to help outline the statics and dynamics of OO designs, before drilling down to code. 

''Even many OO proponents are not so hot on UML.''

And natural language provides a clue - roughly speaking nouns are objects, verbs and adjectives are attributes, verbs are methods so if you write down in PlainEnglish what you want your program to do, right away you can start picking out candidate objects by circling the important nouns. Doesn't matter whether you are talking about BillingSystem objects or EigenVector objects, ObjectOriented methods help to make them almost living, breathing entities in the computer (for the purpose at hand ''i.e.'' churn $M in billing for a telecom company).

''Under ProceduralMethodologies, the nouns and adjectives tend to go in the database, and the verbs as code. However, CollectionOrientedVerbs are factored into a central standard in database-centric shops instead of left to each class/object to reinvent their own (often leading to inconsistency). As far as "living breathing", I can hug and kiss a database also, if in the mood (and my wife is not watching).'' --top

----
''The downside is that GoodDesign with OOP is harder and requires more training than the other mainstream style, procedural programming.''

I disagree with this claim. I argue the opposite, instead. I argue that GoodDesign is hard and requires training (see the BarbiePrinciple). I argue that given comparable effort, training, and skill, the OOP style is more likely to result in GoodDesign than procedural programming.

''I disagree because the principles of good procedural design are clearer and more consistent. Nobody agrees on what good OO design is. Good procedural design hovers around 4 basic principles:''

* OnceAndOnlyOnce (or at least monitoring duplication carefully)
* Group code by task
* StepwiseRefinement
* Use the database, not code, for "noun modeling"

Almost every bad procedural design I have seen stems from the omission of one or more of these 3 rules. I doubt anybody could find 3 similar simple rules for OO design that has even a rough concensus.

Perhaps this should be moved to ProceduralMethodologies, but Wiki has no "#" anchors and there is too much material there.
---------
[1] Walling out the outside world from the class's "guts" is not necessarily about methods versus attributes. Some methods may be internal ("private") and some attributes may be intended to be public. Further, some suggest that ideally the class user shouldn't be able to tell the difference between an attribute and a method such that they can be swapped implementation-wise without changing the public interface. However, not all OOP languages make such transparent swapping easy or seamless. -t
------
This topic made the mistake of getting into alleged "benefits" of OOP. Perhaps it should just describe what it is and not address benefits, otherwise it will go down the difficult and contentious road of tool benefits evaluation and comparison, which is not a trivial topic. -t
----
CategoryDummies