4 ms·

I think that classes (in the school of OOP coming from C++ and Java) are incorrect abstractions. Here incorrect is in the eye of the beholder, but I would argue

by js8 6y ago

I think that classes (in the school of OOP coming from C++ and Java) are incorrect abstractions. Here incorrect is in the eye of the beholder, but I would argue that tying the three fundamental principles of OOP (encapsulation, inheritance, polymorphism) into one abstraction leads to more problems than it solves. In particular in Haskell, these things are separated into modules (encapsulation mechanism), abstract data types (inheritance mechanism) and type classes (polymorphism mechanism). But other modern languages have this separation as well, and it is cleaner. Consider for example a common Java exam question, should you use interface or abstract class? This is a completely artificial problem that doesn't occur in languages that separate these abstractions orthogonally. Also another common exam question, access control (private, public, protected) is more complicated due to lack of the separation of encapsulation and inheritance principles. Another example is Java is arguably much less readable than it could be because organizing all the code as classes makes code more difficult to follow (especially without IDE it's insanity of directories) - you don't know which classes are just utility types or simple functions and which actually contain the meat of the code. A properly organized module is much more pleasant to work with.

legerdemain 6y ago
In Java, it is perfectly acceptable to have either a file containing the primary public class and any number of private utility and implementation classes, or just have a non-instantiatable enclosing class that works as a module and a bunch of interfaces, classes, and enums within it. Consumers then can then refer to them either by their Class.SubClass name or the shorter SubClass name.
- js8 6y ago
  OK, thanks! I didn't realize it is possible, I haven't seen code that uses this technique.
  - watwut 6y ago
    Typically nested classes in Java make it harder to follow what each class does, where it ends and starts. The files then tend to become too big and at worst end up cross referencing each others privates too much. At least, that is my experience with code that uses nested classes all the time and - I am slowly refactoring it to split classes into separate files.
MaxBarraclough 6y ago
I'm reminded of Mike Acton's 3 Lies of Object Oriented Programming. Lie 2: Code should be designed around a model of the world. He makes the point that object-oriented models can never really model real-world objects, and shouldn't try to. A game engine may have several ways of representing a chair, for instance (a physics chair, a breakable chair, a static chair, a usable chair). These probably shouldn't share an interface, despite all relating to real-world chairs. https://youtu.be/rX0ItVEVjHc?t=1154 https://youtu.be/rX0ItVEVjHc?t=1154
- watwut 6y ago
  Ok, but that is argument against idea that died 20 years ago. I cant think of a code written in last years that would try to model real world or blog post that would promoted the idea of modeling real world in classes.
  - jcelerier 6y ago
    A big problem is that university teachers are sometimes stuck 20+ years ago and teach that to students every year - one teacher can hurt a hundred+ students every year. And then we have to undo the damage when they join the workforce. e.g. take this example (sorry guys if you see that, I googled for PassagerStandard) : https://github.com/sbrouard/public-transport-manager/tree/master/TD6/FabriqueTec/src https://github.com/sbrouard/public-transport-manager/tree/ma... - during a whole semester you model a freakin bus with different "passengers" - "standardpassenger", "stressedpassenger", and the bus stops also have behaviour modeled by objects like "CarefulStop", "PoliteStop", etc... The whole thing is basically worst-case OOP where everything is modeled by an interconnected mess of objects and every exercise becomes just worse and worse than the previous. And students have to learn to do that every year and are judged on how "well" they did apply OOP techniques in order to graduate. (note to reader - the authors of this repos are students who had to implement this mess, not the authors of this exercice)
    - MaxBarraclough 6y ago
      > "passengers" - "standardpassenger", "stressedpassenger" That sounds pretty terrible. I presume passengers are unable to change state? Or is the instance replaced with an instance of another class?
inopinatus 6y ago
The underlying misconception is that inheritance and polymorphism are OOP fundamentals. c.f. http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://www.purl.org/stefan_ram/pub/doc_kay_oop_en and both C++ & Java certainly do thereby walk themselves into algebraic incontinence.
- js8 6y ago
  I deliberately didn't want to get into Kay argument and the debate, because it is irrelevant to my point, if you don't want to call whatever Java/C++ is doing OOP, that is fine. But if you have to ask, I think Kay is wrong too. I appreciate his vision, which is inspired by biology, but I think it's not the right way to go about building software systems, either.
  - inopinatus 6y ago
    The definition of OOP is super relevant when the definition encodes principles and abstractions in a discussion of ... principles and abstractions. It’s not a matter of what you or I want. Inheritance and polymorphism are incoherently designed in C++ and Java, but this isn’t a consequence of OOP. It’s a consequence of language designers experimenting and compromising. Re. second point, I didn’t ask, so I won’t be stating my own opinion, but I will state my favourite OO language: Erlang.

by js8 6y ago

legerdemain 6y ago

In Java, it is perfectly acceptable to have either a file containing the primary public class and any number of private utility and implementation classes, or just have a non-instantiatable enclosing class that works as a module and a bunch of interfaces, classes, and enums within it. Consumers then can then refer to them either by their Class.SubClass name or the shorter SubClass name.

js8 6y ago
OK, thanks! I didn't realize it is possible, I haven't seen code that uses this technique.
- watwut 6y ago
  Typically nested classes in Java make it harder to follow what each class does, where it ends and starts. The files then tend to become too big and at worst end up cross referencing each others privates too much. At least, that is my experience with code that uses nested classes all the time and - I am slowly refactoring it to split classes into separate files.

MaxBarraclough 6y ago

I'm reminded of Mike Acton's 3 Lies of Object Oriented Programming. Lie 2: Code should be designed around a model of the world. He makes the point that object-oriented models can never really model real-world objects, and shouldn't try to. A game engine may have several ways of representing a chair, for instance (a physics chair, a breakable chair, a static chair, a usable chair). These probably shouldn't share an interface, despite all relating to real-world chairs. https://youtu.be/rX0ItVEVjHc?t=1154 https://youtu.be/rX0ItVEVjHc?t=1154

watwut 6y ago
Ok, but that is argument against idea that died 20 years ago. I cant think of a code written in last years that would try to model real world or blog post that would promoted the idea of modeling real world in classes.
- jcelerier 6y ago
  A big problem is that university teachers are sometimes stuck 20+ years ago and teach that to students every year - one teacher can hurt a hundred+ students every year. And then we have to undo the damage when they join the workforce. e.g. take this example (sorry guys if you see that, I googled for PassagerStandard) : https://github.com/sbrouard/public-transport-manager/tree/master/TD6/FabriqueTec/src https://github.com/sbrouard/public-transport-manager/tree/ma... - during a whole semester you model a freakin bus with different "passengers" - "standardpassenger", "stressedpassenger", and the bus stops also have behaviour modeled by objects like "CarefulStop", "PoliteStop", etc... The whole thing is basically worst-case OOP where everything is modeled by an interconnected mess of objects and every exercise becomes just worse and worse than the previous. And students have to learn to do that every year and are judged on how "well" they did apply OOP techniques in order to graduate. (note to reader - the authors of this repos are students who had to implement this mess, not the authors of this exercice)
  - MaxBarraclough 6y ago
    > "passengers" - "standardpassenger", "stressedpassenger" That sounds pretty terrible. I presume passengers are unable to change state? Or is the instance replaced with an instance of another class?

inopinatus 6y ago

The underlying misconception is that inheritance and polymorphism are OOP fundamentals. c.f. http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://www.purl.org/stefan_ram/pub/doc_kay_oop_en and both C++ & Java certainly do thereby walk themselves into algebraic incontinence.

js8 6y ago
I deliberately didn't want to get into Kay argument and the debate, because it is irrelevant to my point, if you don't want to call whatever Java/C++ is doing OOP, that is fine. But if you have to ask, I think Kay is wrong too. I appreciate his vision, which is inspired by biology, but I think it's not the right way to go about building software systems, either.
- inopinatus 6y ago
  The definition of OOP is super relevant when the definition encodes principles and abstractions in a discussion of ... principles and abstractions. It’s not a matter of what you or I want. Inheritance and polymorphism are incoherently designed in C++ and Java, but this isn’t a consequence of OOP. It’s a consequence of language designers experimenting and compromising. Re. second point, I didn’t ask, so I won’t be stating my own opinion, but I will state my favourite OO language: Erlang.