

Does a clear definition of "OOP" even exist? - loup-vaillant

My problem is that I never saw a clear definition of OOP<p>I often see quick judgements ("OOP rules/sucks"), or deep superior wisdom ("good OOP is hard"), which don't actually tell anything.  I often read about bundling functions and data together, and encapsulation, but plain modules (or C compilation units) already do that.  I hear about inheritance, but not all OO code use that, and we even tend to avoid it in favour of composition, these days.<p>The closest to a clear definition of OO I know of is http://www.info.ucl.ac.be/~pvr/paradigms.html  According to this, OOP would be records + functions + named state + closures.  But so is stateful functional programming…<p>From what I see, OOP is nothing more than syntactic sugar wrapped up in an aura of mystery.  However, my priors that the majority of the programming community can fall in such an obvious trap are quite low.<p>I notice that I am confused.<p>So, are my observations flawed?  Or are programmers less rational than I thought?
======
terrywilcox
Don't confuse object oriented concepts and philosophies with implementation.
The two are quite different.

There's also no single definition of OOP because it has evolved over the
years.

Start here: <http://www.c2.com/cgi/wiki?DefinitionsForOo>

It's important to learn the ideas before you get tied to an implementation.

~~~
loup-vaillant
Thank you very much for the link.

What exactly do you mean by "implementation"? I didn't talk about any specific
language or framework.

~~~
terrywilcox
Object Orientation is a design philosophy, not a concrete process or
mechanism.

Its major principle is encapsulation; things outside of me don't need to know
about my internal workings, just my external appearance. This leads to
abstraction; if I externally appear just like that other guy, things outside
of me can pretend we're the same even if we have different internal workings.

Beyond those concepts, we begin to get into implementation.

Classes, inheritance, and polymorphism are implementation. You can apply OO
principles without them. They just happen to be the traditional face of OO.

That may be why you're struggling to find a definition that makes sense. Too
often we use the implementation to discuss the philosophy.

Don't get hung up on a definition. It's like trying to define love, art, or
pornography.

Keep asking and arguing about it though. That's a good way to learn it.

~~~
loup-vaillant
OK, but if I admit your principles as OO, then a functional language with
modules and parametric polymorphism is OO (Haskell and Ocaml come to mind).

Your definition seems reasonable, but following it means that giving any
language reasonable facilities for low coupling and code reuse makes it OO.
I'm fine with that, but such a broad term can't be useful in technical
discussions.

~~~
terrywilcox
I think you'll find that the basic principles of good design are shared
between most design philosophies. Reducing coupling and increasing cohesion
spring to mind.

Stop thinking in terms of whether a language claims to be object oriented and
start thinking in terms of how you'd apply object oriented principles to the
language.

The language is merely a tool, sometimes with support for a specific
implementation of object orientation. How you use that tool is up to you.

~~~
loup-vaillant
I did start with the techniques, then checked if the languages supported them.
My ideas are a lot clearer than you seem to think. Thanks to you and the
others, I now have resolved my confusion: "OO" doesn't technically mean
anything significant, but nevertheless carries a strong emotional load
(positive or negative, depending on the reader). That tends to end useful
discussion and to encourage religious flame-wars. I now consider "OO" taboo,
along with sentences like "just a tool". I now believe that most programmers
did fall in the trap I spoke of in my original post, but this trap appears to
be less obvious than I thought.

Now about what implements what:

Coupling reduction is implemented by encapsulation. There's no other way. Any
technique that reduces coupling is a form of encapsulation. Any language that
supports coupling reduction supports encapsulation.

Encapsulation is supported by 3 features: functions, modules, and classes.
Let's not talk about functions, whose presence don't differentiate. So, to
support encapsulation (and therefore coupling reduction), a language needs
either modules or classes.

Code reuse is achieved with functions and abstraction as you defined it. I
don't know any other way, short of writing a DSL or using a whole program. As
before, let's not talk about functions themselves. Therefore, any language
that supports code reuse supports abstraction.

Abstraction means I can interact the same way with two "things" if they are of
the same type. Well, I think that by "guy", you meant "something with embedded
behaviour", and not just dead data, like integers or arrays. Such a thing is
necessarily a closure. Closures can be achieved by 3 mechanisms: subtype
polymorphism (interfaces, mixins…), duck typing, and first class functions
(which are isomorphic to duck typed mono-method objects). I said "parametric
polymorphism" earlier, but it isn't actually needed. So, to supports
abstraction (and therefore code reuse), a language must have either subtype
polymorphism or first class functions.

Now Back to OO.

To support OO, a language must support encapsulation and abstraction. I've
established that it's the same as saying that it must support coupling
reduction and code reuse. And intuitively, a language that doesn't support
either of them isn't worth using. Therefore any modern language should support
OO.

Now, supporting OO is not the same as _being_ OO. To be OO in my book, a
language must actually strongly encourage the frequent use of encapsulation
and abstraction. As it happens, most modern languages do.

Almost all have either modules or classes. And when they do, they strongly
encourage you to use them systematically, if they do not flatly mandate it
like Java.

Likewise, almost all have either subtype polymorphism, duck typing, or first
class functions. And when they do, they strongly encourage their frequent use.

Which means that almost every modern language strongly encourages the frequent
use of all the necessary OO features. In other words, almost every modern
language is OO. C++ and Java are OO because of their classes and subtype
polymorphism. Ocaml and Haskell are OO because of their module system and
their first class functions. You probably didn't intend to qualify those last
two as OO (I don't, and they don't claim to be), but they fit your definition
nevertheless.

~~~
terrywilcox
I don't qualify any languages as OO, their creators do. You can do OO in any
language, with varying degrees of difficulty and success. The language merely
tries to provide mechanisms for encouraging object oriented design (or not).

You appear to need some strict boundaries between different classes of
languages. Those boundaries rarely exist. Languages and the people that define
them are influenced by what they've already learned. There's nothing to stop
language designers from trying to combine elements from various different
types of languages, nor should there be.

Languages evolve. Philosophies evolve. Terminology evolves. Expecting to find
a rigid definition within so much change is naive. Your definition will be
obsolete before you get it written down.

As for religious flame wars, whatever. Ideas don't cause flame wars, people
do. The tone of your post is certainly slanted toward starting one, so I'm
leaving before it happens.

I hope I've been of some assistance and I hope you find what you're looking
for. I fear you'll be disappointed. Personally, I prefer a more pragmatic than
academic approach to software development.

~~~
loup-vaillant
First and foremost: you _have_ been of assistance.

In <http://news.ycombinator.com/item?id=1808634> I've already said what I mean
when I qualify some language as OO. Now your acceptance or rejection of this
definition is not important. What is important is that Ocaml and Haskell both
strongly encourage the use of OO _as you defined it_ , that they greatly
facilitate it, and that they even make it the standard way of writing
programs. I insist because that's definitely _not_ what one would say at
first, especially starting from the reasonable looking definition of OO you
provided.

I don't need strict boundaries between languages, I see them. Some languages
have automatic currying, some do not. Some have duck typing, some have type
inference… and so on. A single difference in two languages' core features can
make them quite different. Of course, if you measure languages along a single
given axis (like the OO/not OO axis), the boundaries appear much smoother. By
the way, I don't see how the fact that language designers are influenced by
the languages they learned support (or refute) the assertion that the
boundaries between languages aren't strict.

> _Languages evolve. Philosophies evolve. Terminology evolves. Expecting to
> find a rigid definition within so much change is naive. Your definition will
> be obsolete before you get it written down._

Beware. That, is very close to a _semantic stop sign_
<http://wiki.lesswrong.com/wiki/Semantic_stopsign> While true, (Languages,
philosophies and terminology do evolve), it is suggesting that it makes any
conversation whatsoever impossible. If you don't want to discuss further, just
say so (saying "I'm leaving before [a flame war] happens" was perfectly fine).
Now, if you _do_ think that the meaning of the term "OO" evolve so fast that
it's not worth writing down, then you'll agree that the term "OO" itself
shouldn't be used at all..

I didn't say that Ideas cause flame wars. I said that using some _terms_
,which aren't the ideas themselves, can cause flame wars. (I said «"OO"», not
«OO».) One reason the term "OO" can cause flame wars is because it triggers
_cached thoughts_ <http://wiki.lesswrong.com/wiki/Cached_thought> which are
difficult to de-construct without a clear, agreed upon definition. And I
certainly don't want to start a flame war with you. You didn't attacked me
personally, nor used any _dark arts_
<http://wiki.lesswrong.com/wiki/Dark_arts> Many people can't say so.

------
spooneybarger
Everyone has their own 'most important bits' of what OOP is. For example, many
people don't consider message passing to be an important part of OOP, others
do. Like any term that corresponds to an idea rather than a thing, each person
is going to have their own take on what that idea is based on their
experiences.

------
snissn
<http://news.ycombinator.com/item?id=1730411>

