Oo Best Feature Poll
Oo Best Feature PollI am curious. Which of the BenefitsOfOo do you consider as being the most important benefit or claim of OO technology or OOP?
Please note, that all points stating with "better" or "easier" compare with another concept, which I take to be basically "StructuredProgramming" (which historically came before OO).
Encapsulation Issue
Note that I consider "encapsulation" too vague or multi-faceted a concept to be in this poll. Sometimes it means physical grouping or related things, sometimes hiding away details, and sometimes GateKeeper.
For those who voted "encapsulation", perhaps we can better divide it using a sub-vote:
I voted "other". OO came with an analysis and design methodology which has proven empirically useful. That's one "best feature" IMO. In addition, it has adapted itself well to new methodologies (e.g. agile programming). So what I think I want to say is that OO is a good model for what programmers want to do.
I also voted "other". I think that OO is a natural way to express the structure of a model and to weave relations between the model elements. By structure I mean identifying the common points, differences and dependencies between the elements.
Shouldn't that be a vote for "Better models human thinking" then?
No, "Better models human thinking" is not correct. What OO does (and not any specific methodology) is force the programmer to understand the problem domain, and understand elements in the domain. This is very difficult (and thus not really natural human thinking). I find that rarely do I spend time on the details of whatever language that I'm using - the time consuming part is mapping the domain into classes, thinking about what the names of these classes are, and whether the classes are correct. The naming is difficult and important - the next programmer should be able to look at a class name, and understand what the class means in terms of the domain.
[If you're modeling the problem domain in terms of classes, but you aren't writing a domain simulator, then you're already doing something wrong. And by "wrong" I mean that it dooms you to all sorts of AccidentalComplexity. OO is for modeling the computation domain, not the problem domain.]
Related: ComputationalAbstractionTechniques
I voted for "Encapsulation" as being closest to what I see as the best feature. The PolyMorphism is pretty good too.
I find it depressing that Polymorphism has only 1 vote. Shows that only 1 of the programmers who responded to this poll actually has a clue about how to take full advantage of OOP.
Nope, I love polymorphism, I just don't consider it the best feature.
IMHO, polymorphism is fundamental to OOP so if you're not using polymorphism, you're not doing OOP at all. I voted for "Better models human thinking" as the most important benefit of OOP. That is, polymorphism is a (the) fundamental mechanism of OOP, not a benefit. -- JasonArhart
I remember AdeleGoldberg describe Smalltalk OO as "ask, but don't touch" (maybe not the exact words). The message sending semantic is the only thing that one needs to know from external point of view. Polymorphism is the key mechanism in implementing message sending. -- BrianZhou?
There is a problem with the categories - they mix levels. For example: "encapsulation" is a way of modeling thinking as is "polymorphism". And in the ambiguity of "important": "reuse" might be the most important claim for those adopting it and "easier to change" the most important benefit for those that have adopted it. -- AlanGriffiths
I'm surprised that so many people selected "Better models human thinking". Procedural coding strikes me as much more intuitive; it just doesn't scale as well as OO.
The trick is to let the database handle the "big picture", not the code. OO tries for giant intertwined wods of code. Yes, procedural generally fails at that, but that is a poor goal anyhow. See SystemSizeMetrics and ProceduralMethodologies.
The database can't handle the big picture... it's not code, it can only hold data! Code must handle the picture!
Example? It is about DivideAndConquer. Let code do what it does best and DB's do what they do best. I personally find code horrible at shared attribute management. OO might be good at encapsulating behavior that is tightly bound to a given noun/entity, but I find it shitty at managing relationships BETWEEN stuff/objects/entities/nouns. It's the relationships. I would rather have the relationship spehgetti in a database where I can query and sort it how I please instead of dealing with a fat wad of class code. Life is easier when you can use attribute and relationship management automation (a database) to sift thru complexity.
There's a problem with the whole question, really: better than what?
Lets assume it is being compared to ProceduralMethodologies and perhaps FunctionalProgramming.
(Moved testing discussion to BenefitsOfOo)
I vote for "Better models human thinking" definitly. One just need to take a look at the vocabulary used in OO programming and design. Neevertheless, when programming/designing/solving a problem, abstraction is the key. OO allows one to easily climb the hill of abstractionism in a way very similar to mental patterns. Of course, OO programmers like me may have already adjusted their own mental process to best fit OO. If this is true, then probably humans don't have a thinking model but an ever-changing adaptative process. Maybe a language where you can define the language itself (meta-language) would be the language that "better model humans thinking". In this case, I sugest another entry in the vote pool for "Human mind better adjusts OO conceptual model".
I'd consider voting some OO code as cleaner, easier to read. It models human thinking better with regards to objects, but it also sometimes models human thinking better with regards to notation, syntax, grammar. It at times seems to have more clarity (although heap memory allocation code can get in the way if there is no stack provided). With brackets and parametersin procedural style code, parameter positions can be accidentally confused (especially in complex monsters like the WinAPI). With assigment and message passing, one can program with more confidence at times since the mixup of parameters is reduced (perhaps named parameters could help, but that is verbose). If my edit box wants to become red, I use a nice short form for "edit box color, please be red". The "please be" is the assigment.
{OO programming...}
Editbox.Color := red; //I read this as "editbox color, please be red"
{versus procedural..}
setColor(Editbox, red); //I read this as "setcolor is multiplied by editbox and by red. Ugh..."
(I read this as "setColor" "Editbox" "Red")
Process ---- Data ---
{hmm.. wait a minute .. could it be:}
setColor(red, editbox); //This is confusing, now I'm waisting time looking up help docs..."
(And I would repackage this into setColor(Editbox, Red) because
it does not parse in a natural manner. (If I could) -- PeterLynch)
OR..
{you could use some bizarre syntax like..}
red,color,editbox,making:it (happen); //No one wants to try and understand this.
//It's harder to decipher.
Setting the color is no different than "assigning" a color. However, the first example above is easier to read, cleaner, and neater on both paper and screen. I'd rather program in sentences than program in some bracketed math equation which I have to decipher (which isn't even a math equation in the first place.. but I thought it was at first glimpse). The first example above is easier to read because I want to "make edit box color red". It happens in that order. In the second example, it does not happen in that order. It happens "set color multiplied by editbox multiplied by red" (math habits... maybe this is another reason?).
Another way of looking at it: the edit box and the color are both similar.. we want to do something to them. They should be separate from "red". They should be grouped together on one side of the equation. When EditBox and Red are both grouped together, it makes less sense. Why are they together? They are not related to each other. An indirect and important factor of the "grouping together" issue the and object issue, is still the syntax of OO.
Ultimately, I think some OO is easier to read. Possibly the notation and syntax itself (of some OO) is a major factor in its usage.
Measuring "easier to read" is generally a very subjective thing. I don't dispute that it may better fit your mind, but one has to be careful about extrapolating personal preferences to every other mind.
As far as setting attributes, in my opinion set/get's are a smell in both OO and procedural (there is a topic around here somewhere on that). Attributes are best treated as data IMO so that the presentation can be varied and information shared with multiple tools and languages. I vote SeparateMeaningFromPresentation so that we can all have our favorite views of the information without having to force our preferred view on others. Whether we see the noun after the verb or vis versa can be a personal view setting. I know separation is a bit idealistic, but can be achieved to some extent if worked at. Code is often not the best place to "store" boatloads of attributes IMO. Code generally makes a lousy database (attribute management system) and reporting tool (presentation manipulator). -- top
Sadly, lots of code out there like in PHP, still uses plenty of
if (isset ($var1)){ //If isset is multiplied by variable 1 hundred dollars, then...
mycode
}
when it could be
if (Expression1.isSet) { //if expression1 is set, then...
my code
}
Maybe these people are living in the past, "oh the good old days when we...".
I am not sure what the point being made here is. Now we have prefix, infix, and postfix verbs. Our languages have gone a bit screwy in that regard. That's not something I'm ready to celebrate.
Encapsulation doesn't strike me as a feature of OO since I commonly use it in languages that don't consider themselves OO languages. Polymorphism seems like the key feature of OO, since it's when I need polymorphism that I'm more likely to choose a language that calls itself OO for the task. --RobertFisher
See also: NobodyAgreesOnWhatOoIs
EditText of this page
(last edited October 25, 2008)
or FindPage with title or text search