5 ms·

With all this angst against OOP, what other alternatives should a programmer consider or what patterns of hierarchical logic do people suggest?

cuddlecake 7y ago
The first question should be whether we need hierarchical logic, or what hierarchical logic is supposed to be.
weberc2 7y ago
Use composition for reuse and interfaces for polymorphism. These can do the same as inheritance and more, and they do it more cleanly. Reuse and polymorphism are orthogonal concerns that inheritance tries to fuse awkwardly together. Try Go if you’d like a familiar language without the inheritance that you can pick up in an afternoon.
- tonyedgecombe 7y ago
  It's not compulsory even in a language that supports it, I'm working on a medium sized C# project that has minimal use of inheritance and only then to fit in with the requirements of a library feature.
  - weberc2 7y ago
    Yeah, I meant it as a learning suggestion, not a “switch your main language” suggestion. Fully agree with you.
collyw 7y ago
Aren't most large systems organized in an OOP manner?
barrkel 7y ago
Hierarchy - a single ontology - is one of the problems with OO. Ontologies - note the plural - are useful, but choosing just one ontology privileges some axis of abstraction over others, but there are different lenses you can put on things that may make you want to classify by different criteria. For example, you might have a bunch of things, some of which: (a) can be rendered in some display - could be console, HTML, print output, screen, don't care; (b) can be serialized to a variety of media; (c) have some common configuration, that interacts with some configuration management system; etc. If you try and shoe-horn these commonalities into a hierarchy, you end up with classes that advertise being able to do too much and need to have "not implemented" error conditions, breaking the Liskov substitution principle. Interfaces are a way of breaking out. They're additive, rather than hierarchical, from the implementing class perspective. The other big problem (a bigger problem IMO) with inheritance is coupling. I don't think there's any closer coupling between two pieces of code in an OOP system than inheritance. Changes in a base class can radically alter behaviour in all descendants. Depending on the implementation of overriding, descendant behaviour can be accidentally hijacked with no compile time or run time warning merely by updating a dependency. The API by which base class and descendant class interact is bidirectional, with the flavours of both library (you call them) and framework (we'll call you), and intermediate internal state when e.g. overridden protected methods are being called is usually sorely undocumented and liable to change.
- marcosdumay 7y ago
  > Interfaces are a way of breaking out. They're additive, rather than hierarchical, from the implementing class perspective. Java (and .Net by copying) choose to make interfaces additive and superclasses combinatorial. It's a design decision and in no way intrinsic. Other languages have different choices.
  - barrkel 7y ago
    Oh, I'm aware. However additive superclasses are much much worse for OOP, there's good reason languages beyond C++ haven't walked the same road.
userbinator 7y ago
It's even harder to define (which might be why OOP is so popular --- it's easy to get dogmatic about "OOP is X", and the cargo-culters will pick it up and spread it like religion), but I'd say "be pragmatic and let it come naturally". Systems tend to naturally form OO-ish things even if they're not written in an OO language; the Linux kernel is one example. I think of OO as just another layer of organisation beyond functions and structures, arising from the desire to group related data and code together.
- zzzcpan 7y ago
  It's not natural. It depends on your previous experience. Preferring C-style semi-OO stateful programming and OO merely shows what influenced your thinking.
tabtab 7y ago
In my opinion we need look at bringing the relational model into code, not just data. OOP is too awkward for complex relationships. Or, at least making code more relational-friendly to avoid the O-R-Impedance-Mismatch: https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch https://en.wikipedia.org/wiki/Object-relational_impedance_mi...
nradov 7y ago
There's nothing particularly wrong with OO as a programming paradigm when used for the right purposes. It was originally designed for simulating real world systems and still works great for that.

cuddlecake 7y ago

The first question should be whether we need hierarchical logic, or what hierarchical logic is supposed to be.

weberc2 7y ago

Use composition for reuse and interfaces for polymorphism. These can do the same as inheritance and more, and they do it more cleanly. Reuse and polymorphism are orthogonal concerns that inheritance tries to fuse awkwardly together. Try Go if you’d like a familiar language without the inheritance that you can pick up in an afternoon.

tonyedgecombe 7y ago
It's not compulsory even in a language that supports it, I'm working on a medium sized C# project that has minimal use of inheritance and only then to fit in with the requirements of a library feature.
- weberc2 7y ago
  Yeah, I meant it as a learning suggestion, not a “switch your main language” suggestion. Fully agree with you.

collyw 7y ago

Aren't most large systems organized in an OOP manner?

barrkel 7y ago

Hierarchy - a single ontology - is one of the problems with OO. Ontologies - note the plural - are useful, but choosing just one ontology privileges some axis of abstraction over others, but there are different lenses you can put on things that may make you want to classify by different criteria. For example, you might have a bunch of things, some of which: (a) can be rendered in some display - could be console, HTML, print output, screen, don't care; (b) can be serialized to a variety of media; (c) have some common configuration, that interacts with some configuration management system; etc. If you try and shoe-horn these commonalities into a hierarchy, you end up with classes that advertise being able to do too much and need to have "not implemented" error conditions, breaking the Liskov substitution principle. Interfaces are a way of breaking out. They're additive, rather than hierarchical, from the implementing class perspective. The other big problem (a bigger problem IMO) with inheritance is coupling. I don't think there's any closer coupling between two pieces of code in an OOP system than inheritance. Changes in a base class can radically alter behaviour in all descendants. Depending on the implementation of overriding, descendant behaviour can be accidentally hijacked with no compile time or run time warning merely by updating a dependency. The API by which base class and descendant class interact is bidirectional, with the flavours of both library (you call them) and framework (we'll call you), and intermediate internal state when e.g. overridden protected methods are being called is usually sorely undocumented and liable to change.

marcosdumay 7y ago
> Interfaces are a way of breaking out. They're additive, rather than hierarchical, from the implementing class perspective. Java (and .Net by copying) choose to make interfaces additive and superclasses combinatorial. It's a design decision and in no way intrinsic. Other languages have different choices.
- barrkel 7y ago
  Oh, I'm aware. However additive superclasses are much much worse for OOP, there's good reason languages beyond C++ haven't walked the same road.

userbinator 7y ago

It's even harder to define (which might be why OOP is so popular --- it's easy to get dogmatic about "OOP is X", and the cargo-culters will pick it up and spread it like religion), but I'd say "be pragmatic and let it come naturally". Systems tend to naturally form OO-ish things even if they're not written in an OO language; the Linux kernel is one example. I think of OO as just another layer of organisation beyond functions and structures, arising from the desire to group related data and code together.

zzzcpan 7y ago
It's not natural. It depends on your previous experience. Preferring C-style semi-OO stateful programming and OO merely shows what influenced your thinking.

tabtab 7y ago

In my opinion we need look at bringing the relational model into code, not just data. OOP is too awkward for complex relationships. Or, at least making code more relational-friendly to avoid the O-R-Impedance-Mismatch: https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch https://en.wikipedia.org/wiki/Object-relational_impedance_mi...

nradov 7y ago

There's nothing particularly wrong with OO as a programming paradigm when used for the right purposes. It was originally designed for simulating real world systems and still works great for that.