Object Oriented For Dummies
Object Oriented For DummiesCan 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.
// WickedPotrzebie adds the notion of wickedness to Potrzebie.
// It also redefines farshimmeltization to take wickedness into account.
class WickedPotrzebie 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 WickedPotrzebie();
// 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:
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 HolyWars.
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.
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.
-- 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:
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
EditText of this page
(last edited September 11, 2012)
or FindPage with title or text search