

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
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
> 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
"Rifle-oriented programming": [http://blog.thinkrelevance.com/2009/8/12/rifle-
oriented-prog...](http://blog.thinkrelevance.com/2009/8/12/rifle-oriented-
programming-with-clojure-2)

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.

~~~
Jach
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
Without encapsulation, what do you pass a message _to_?

(Honestly curious)

~~~
DougWebb
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...](http://gbracha.blogspot.com/2009/11/objects-are-not-hash-tables.html)

~~~
jules
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.

