4 ms·

> Studying the copious literature of OO, the central features which define an OO system seem a little ill-defined. I didn't know opinion pieces could be disgui

> Studying the copious literature of OO, the central features which define an OO system seem a little ill-defined. I didn't know opinion pieces could be disguised as academia. Of course the article has some interesting points about human memory, but that's why we have things like single responsibilities.

exDM69 9y ago
But it is not an opinion. There is no universally accepted definition of OO let alone a formal, axiomatic definition, and that makes it ill-defined. If you disagree, point to a definition of OO that you think is "correct".
- Ace17 9y ago
  I suggest to look at Alan Kay's definition, since he's the one who invented the term "object oriented". http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
  - exDM69 9y ago
    Well, Alan Kay's definition is just one definition and as evidenced by the rest of this thread, it's far from being universally accepted and definitely not the definition used in the mainstream "OO" languages. Further, that email thread is far from being a formal definition. In that email there's a pointer to a ISO standard doc, but that's hardly authoritative either. It seems like every language (and every programmer) has their own idea of OO, which is why I consider it quite apt to call it "ill-defined". That's not to say that OO programming itself is bad, more that the term "OO" is bad.
- eksemplar 9y ago
  I'm not disputing the opinion, rather the fact that the author doesn't document why the opinion is there. Maybe the author went through research on the subject and found a consensus, but maybe not.
yen223 9y ago
> that's why we have things like single responsibilities I would argue that single responsibilities is nice to have. However, OO-style objects are responsible for both data and behaviour. Object-oriented languages themselves violate the SRP, to its own detriment. Both functional and imperative languages tend to encourage separation of data and behaviour. I can operate on the same data structure implemented under a different context, without having to bring in its unrelated set of methods. This leads to cleaner code reuse and looser coupling - both nice properties to have in a complex codebase.

exDM69 9y ago

But it is not an opinion. There is no universally accepted definition of OO let alone a formal, axiomatic definition, and that makes it ill-defined. If you disagree, point to a definition of OO that you think is "correct".

Ace17 9y ago
I suggest to look at Alan Kay's definition, since he's the one who invented the term "object oriented". http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
- exDM69 9y ago
  Well, Alan Kay's definition is just one definition and as evidenced by the rest of this thread, it's far from being universally accepted and definitely not the definition used in the mainstream "OO" languages. Further, that email thread is far from being a formal definition. In that email there's a pointer to a ISO standard doc, but that's hardly authoritative either. It seems like every language (and every programmer) has their own idea of OO, which is why I consider it quite apt to call it "ill-defined". That's not to say that OO programming itself is bad, more that the term "OO" is bad.
eksemplar 9y ago
I'm not disputing the opinion, rather the fact that the author doesn't document why the opinion is there. Maybe the author went through research on the subject and found a consensus, but maybe not.

yen223 9y ago

> that's why we have things like single responsibilities I would argue that single responsibilities is nice to have. However, OO-style objects are responsible for both data and behaviour. Object-oriented languages themselves violate the SRP, to its own detriment. Both functional and imperative languages tend to encourage separation of data and behaviour. I can operate on the same data structure implemented under a different context, without having to bring in its unrelated set of methods. This leads to cleaner code reuse and looser coupling - both nice properties to have in a complex codebase.