What Object-Oriented essentially means

[beza1e1]

http://beza1e1.tuxen.de/articles/oop.html

[Deestan]

I think this article is uneducated and useless.

He declares OO superior to all other paradigms by giving a few scenarios where it is better than procedural programming.

As far as I can see, all the Good Things he points out in OO are (often better) implemented in functional languages.

[beza1e1 → Deestan]

The article doesn't compare OOP to anything. It tries to define OOP and considers it necessity.

Personally i think FP is complementary to OOP and Haskell could be OOP according the articles definition (OOP=polymorphism). Maybe someone who knows Haskell better than me can comment on that?

(disclaimer: i'm the author)

Update: I just saw that i did write "OOP is better than other paradigms" and corrected that. Sorry!

[Deestan → beza1e1]

> I just saw that i did write "OOP is better than other paradigms" and corrected that.

Good. :) I guess it was mainly that sentence that got me into the wrong mindset. I read through the rest believing that it was along the same lines.

I retract my complaint.

[cchooper]

If object-orientation means X then why don't people just call it X?

If object-orientation is polymorphism then how come many polymorphic languages aren't object-oriented?

At the very most, object-orientation is a particular mechanism for achieving a particular kind of polymorphism (namely ad-hoc object-based polymorphism). At most. Given the vagueness of the term, it could not even be that.

[pavelludiq → cchooper]

"Rifle-oriented programming": http://blog.thinkrelevance.com/2009/8/12/rifle-oriented-prog...

After reading the above article, one could argue that if the definition of object oriented programming is flexible enough, clojure fits it. But we hit a philosophical problem. If clojure is object oriented because it can do all the stuff that oo languages can do, then oop becomes a meaningless metaphor, just a name for a set of common sense ideas. Oop NEEDS to be defined in terms of traditional object systems(with classes and methods and stuff like that) in order to make sense as a paradigm. If you define oop as "a general metaphor in which everything is an object and objects interact with each other via message passing" you can implement it in a variety of ways, all of which would be object oriented.

Simply put, if you don't have the concrete mechanics, the name you had for the result doesn't make sense anymore. Wow, i knew oop was a vaguely defined term, but i didn't know just how fragile its definition was until i started writing this comment.

[tumult]

A good read for anyone who has been in the same (delusional) position as this author, and can look back with fond memories of drinking that same Kool-Aid.

[AndrewDucker]

I'd say that Encapsulation was the primary property of OOP - taking a bunch of variables and functions and wrapping them up together.

Polymorphism is probably second, with interface implementation being more useful than inheritance a lot of the time.

Polymorphism would come third.

[kls → AndrewDucker]

The problem is the traditional languages that one would reference as symbols of OOP, have all embraced an Anemic Domain Model anti-pattern for their standard development best practices, this kind of negates some of the higher level advantages of OOP.

[scott_s → AndrewDucker]

Quoth Alan Kay, taken from the article: OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

That's, in order, message passing, encapsulation and polymorphism. I think his primary goal was message passing and late binding; encapsulation is how to implement that. That doesn't mean encapsulation is more important.

[Jach → AndrewDucker]

I figure the whole concept of message passing is the heart of OOP, with encapsulation being a tidy way to go about it and inheritance and polymorphism being nice, powerful add-ons.

[AndrewDucker → Jach]

Without encapsulation, what do you pass a message _to_?

(Honestly curious)

[DougWebb → AndrewDucker]

Encapsulation generally refers to private data, but you could define classes that are just collections of methods, and you can define interfaces that are just collections of method signatures. An object which claims to support an interface can accept any of the messages defined by that interface, and another object can pass messages based on that.

A javascript example: in javascript, functions are objects, and can have methods.

    function MyFunction(...) { ... };
    MyFunction.method1 = function(...) {...};
    MyFunction.method2 = function(...) {...};
    MyFunction.method3 = function(...) {...};

Now, you can pass the messages 'method1', 'method2', or 'method3' to MyFunction. Message passing without encapsulation (as it's usually thought of.)

Of course, MyFunction has some default properties too, and you can define more:

    MyFunction.data1 = ...;
    MyFunction.data2 = ...;

That gives you traditional encapsulation, especially if you use somewhat more complex syntax to make the data private instead of public.

[grogers]

I've never really heard anyone define OOP past "I'd know it when I see it". At least this article explicitly picks polymorphism as a language feature that defines whether it is OO or not. But basically every modern language has polymorphism in some form - even C has function pointers.

OOP is just another in a long line of broad categories that doesn't really mean much. Pretty much all languages are procedural, functional, object-oriented, declarative languages.

[davidmathers]

Gilad Bracha says: "For me, an object is an encapsulated self referential record."

http://gbracha.blogspot.com/2009/11/objects-are-not-hash-tab...

[jules → davidmathers]

That is a very narrow definition that depends on implementation details.

[DanielBMarkham]

It's amazing that you can understand so much of OOP and yet understand so little of OOP.

OOP is a way of structuring code and data to allow large numbers of people to be able to create and maintain solutions. The focus is on the structuring. Language features are not relevant in as much as they support or don't support that structuring.

If you don't understand what your goal is -- if you think languages are just various collections of features -- you won't know if you got there or not. The game was up with this author when he defined OOP by doing a simple intersection of feature-sets. Ugh.