6 ms·

It's "pure fashion" until you try to massage your new subclass into behaving slightly differently when you're living with class hierarchies that are N levels de

It's "pure fashion" until you try to massage your new subclass into behaving slightly differently when you're living with class hierarchies that are N levels deep. Clean compositions, ala Scala traits, can be done with OO. It's just not something I've seen in the wild, or something actively encouraged by any OO teachings I've witnessed. At the same time, composition is pretty much the only way FP is taught (at least in my experience).

0815test 7y ago
This, basically. People should stop thinking about "composition vs. inheritance" and start thinking of implementation-inheritance and thus OOP in a strict sense as "composition plus open recursion". Open recursion (viz. the fact that methods defined on your "base" classes can invoke 'virtual' methods on self and end up depending on behavior that may have been overridden at any level in the class hierarchy) is quite often a misfeature and not what you actually want, given that the invariants involved in making its use meaningful or sane are extremely hard to usefully characterize.
- barrkel 7y ago
  Open recursion is pretty much core to the most useful OOP idiom, which I would assert is UI component toolkits. UI heavily relies on a large number of conventions that the user learns to expect to cat in certain ways. You can parameterize a UI widget that encapsulates these conventions with function pointers or overridden methods, but the end result is pretty much the same. I'll strongly agree however that far too few programmers in OO languages pay enough attention to the hard problem of designing for extension. It's the reason that C#, unlike Java, defaults to non-virtual methods.
  - slifin 7y ago
    Except UI trees are probably the worse place for objects In PHP for example all query builders are meant to be used as a tree of objects, which means if you want to recursively change the table names used by the query you're out of luck because that state is often private and behaviour not implemented Or maybe you want to inspect the query as data at runtime or assert against its shape or deeply update or delete or copy or compose parts of it all of those things are difficult But use a data oriented library and suddenly they're easy transparent and predictable, self plug : https://github.com/slifin/beeline-php https://github.com/slifin/beeline-php See hiccup for a data oriented UI HTML tree, honeySQL for SQL there's one for css, routing, there's some for all of the state of your app like redux and Integrant As soon as you have a tree of objects your coworkers won't know how your objects work till you train them and even then it won't be as powerful as your standard library, but your coworkers do know how to manipulate arrays vectors maps sets dictionaries etc self made objects are obtuse in these use cases
    - barrkel 7y ago
      VB, Delphi and WinForms have all been pretty successful in their domains. You'll need to work harder to convince me, and many other people, that their use of objects was the worst. The objects are part of the standard library, that's practically a given when talking about OO UI. Objects are a bit weaker for UI as a projection of a domain data model, especially when it needs to be reactive to changes in the underlying data. The more the UI is data-bound, the more I prefer a functional / data flow idiom.
  - taurath 7y ago
    When the goal is to model something “in real life” OOP tends to map decently well and it’s easy to teach. When you’re trying to make sure your program isn’t going to go off the rails, limits on mutation is one of the first places to look. When your software has 50mm+ valid states, one should hopes they have a large manual QA team. If you have all the possible states held in their own subsystem, you can automate stability much more easily.
    - TeMPOraL 7y ago
      Not even there. Classical OOP forces you to organize around a single and very specific taxonomy; things "in real life" are usually the very opposite of that. I remember textbook examples of inheritance with shapes or animals, both of which actually show clearly why it's a bad idea.
      - kamaal 7y ago
        >>I remember textbook examples of inheritance with shapes or animals Man, I wonder how people went through this wondering, Who uses this? Can't they show us something real! Eventually you just kind of tune out, because when you often meet the real world use cases, OO either descends to hierarchical verbosity from hell with layers and layers of generic abstract stuff when things should be more direct.
    - cutler 7y ago
      Why is modelling in OOP any more "real life" than with other programming paradigms? I've heard this many times from OOP zealots but I just don't get it. Most examples of this I've seen focus on physical objects such as cars which is just ludicrous as your average piece of software is morel likely to be dealing with a data structure, such as a user profile, than anything physical.
      - repolfx 7y ago
        Game engines tend to model real life and they are usually very OOP.
Const-me 7y ago
> It's just not something I've seen in the wild I don't code Scala, but aren't these traits approximately same as interfaces in C#? Interfaces are used a lot in the wild, including in the standard library, they're often generic, IEnumerable<T>, IComparable<T>, and so on.
michaelscott 7y ago
Exactly this. I think this is the issue with OO that developers have come to realise, and which more functional languages get around. It's the "banana, gorilla, forest" problem that Joe Armstrong of Erlang once mentioned in a book I think, and it boils down to the lack of care when considering separation of concerns. Of course you can separate concerns properly in an OO context, but most developers don't. It's much easier to consider properly when the entire language is structured around it.
- xtracto 7y ago
  I think I understand what you meant. I like comparing it with the Directories vs Labels comparison (that presumably was won by Labels). Back when Gmail just started, one of the things that it made different from other web-mail services (including hotmail) was letting you "label" emails instead of "moving them" to folders. The problem with Directories was that, at some point, content might have two different classifications, so the question of putting it in two directories arises (if using that abstraction). Same thing happens with Object hierarchies, even if you start meticulously defining the hierarchy of your objects given the current domain you are mapping, chances are in 2 years you will get a trait/data that does not really fall in one of your defined objects, and you will struggle to put it in one or the other, and your encapsulation will start breaking. That happens "in practice" in real life, and is something that tons of books about OOD, OOA, and OOP define as incorrect architecture in theory, but there was always a disconnect.

0815test 7y ago

This, basically. People should stop thinking about "composition vs. inheritance" and start thinking of implementation-inheritance and thus OOP in a strict sense as "composition plus open recursion". Open recursion (viz. the fact that methods defined on your "base" classes can invoke 'virtual' methods on self and end up depending on behavior that may have been overridden at any level in the class hierarchy) is quite often a misfeature and not what you actually want, given that the invariants involved in making its use meaningful or sane are extremely hard to usefully characterize.

barrkel 7y ago
Open recursion is pretty much core to the most useful OOP idiom, which I would assert is UI component toolkits. UI heavily relies on a large number of conventions that the user learns to expect to cat in certain ways. You can parameterize a UI widget that encapsulates these conventions with function pointers or overridden methods, but the end result is pretty much the same. I'll strongly agree however that far too few programmers in OO languages pay enough attention to the hard problem of designing for extension. It's the reason that C#, unlike Java, defaults to non-virtual methods.
- slifin 7y ago
  Except UI trees are probably the worse place for objects In PHP for example all query builders are meant to be used as a tree of objects, which means if you want to recursively change the table names used by the query you're out of luck because that state is often private and behaviour not implemented Or maybe you want to inspect the query as data at runtime or assert against its shape or deeply update or delete or copy or compose parts of it all of those things are difficult But use a data oriented library and suddenly they're easy transparent and predictable, self plug : https://github.com/slifin/beeline-php https://github.com/slifin/beeline-php See hiccup for a data oriented UI HTML tree, honeySQL for SQL there's one for css, routing, there's some for all of the state of your app like redux and Integrant As soon as you have a tree of objects your coworkers won't know how your objects work till you train them and even then it won't be as powerful as your standard library, but your coworkers do know how to manipulate arrays vectors maps sets dictionaries etc self made objects are obtuse in these use cases
  - barrkel 7y ago
    VB, Delphi and WinForms have all been pretty successful in their domains. You'll need to work harder to convince me, and many other people, that their use of objects was the worst. The objects are part of the standard library, that's practically a given when talking about OO UI. Objects are a bit weaker for UI as a projection of a domain data model, especially when it needs to be reactive to changes in the underlying data. The more the UI is data-bound, the more I prefer a functional / data flow idiom.
- taurath 7y ago
  When the goal is to model something “in real life” OOP tends to map decently well and it’s easy to teach. When you’re trying to make sure your program isn’t going to go off the rails, limits on mutation is one of the first places to look. When your software has 50mm+ valid states, one should hopes they have a large manual QA team. If you have all the possible states held in their own subsystem, you can automate stability much more easily.
  - TeMPOraL 7y ago
    Not even there. Classical OOP forces you to organize around a single and very specific taxonomy; things "in real life" are usually the very opposite of that. I remember textbook examples of inheritance with shapes or animals, both of which actually show clearly why it's a bad idea.
    - kamaal 7y ago
      >>I remember textbook examples of inheritance with shapes or animals Man, I wonder how people went through this wondering, Who uses this? Can't they show us something real! Eventually you just kind of tune out, because when you often meet the real world use cases, OO either descends to hierarchical verbosity from hell with layers and layers of generic abstract stuff when things should be more direct.
  - cutler 7y ago
    Why is modelling in OOP any more "real life" than with other programming paradigms? I've heard this many times from OOP zealots but I just don't get it. Most examples of this I've seen focus on physical objects such as cars which is just ludicrous as your average piece of software is morel likely to be dealing with a data structure, such as a user profile, than anything physical.
    - repolfx 7y ago
      Game engines tend to model real life and they are usually very OOP.

Const-me 7y ago

> It's just not something I've seen in the wild I don't code Scala, but aren't these traits approximately same as interfaces in C#? Interfaces are used a lot in the wild, including in the standard library, they're often generic, IEnumerable<T>, IComparable<T>, and so on.

michaelscott 7y ago

Exactly this. I think this is the issue with OO that developers have come to realise, and which more functional languages get around. It's the "banana, gorilla, forest" problem that Joe Armstrong of Erlang once mentioned in a book I think, and it boils down to the lack of care when considering separation of concerns. Of course you can separate concerns properly in an OO context, but most developers don't. It's much easier to consider properly when the entire language is structured around it.

xtracto 7y ago
I think I understand what you meant. I like comparing it with the Directories vs Labels comparison (that presumably was won by Labels). Back when Gmail just started, one of the things that it made different from other web-mail services (including hotmail) was letting you "label" emails instead of "moving them" to folders. The problem with Directories was that, at some point, content might have two different classifications, so the question of putting it in two directories arises (if using that abstraction). Same thing happens with Object hierarchies, even if you start meticulously defining the hierarchy of your objects given the current domain you are mapping, chances are in 2 years you will get a trait/data that does not really fall in one of your defined objects, and you will struggle to put it in one or the other, and your encapsulation will start breaking. That happens "in practice" in real life, and is something that tons of books about OOD, OOA, and OOP define as incorrect architecture in theory, but there was always a disconnect.