• CapeWearingAeroplane@sopuli.xyz
    link
    fedilink
    arrow-up
    5
    ·
    1 month ago

    Can someone please enlighten me on what makes inheritance, polymorphism, an operator overloading so bad? I use the all regularly, and have yet to experience the foot cannons I have heard so much about.

    • Heavybell@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 month ago

      If the only tool you have is a hammer, everything looks like a nail.

      That’s the only thing I can think to answer your question. There are some problems that are best solved with other tools, like text parsing for example you might want to call out to some code written in a functional language.

      • CapeWearingAeroplane@sopuli.xyz
        link
        fedilink
        arrow-up
        3
        ·
        1 month ago

        Oh, thanks then! I’ve heard people shred on OOP regularly, saying that it’s full of foot-canons, and while I’ve never understood where they’re coming from, I definitely agree that there are tasks that are best solved with a functional approach.

    • modeler@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      1 month ago

      I don’t think that the anti-oop collective is attacking polymorphism or overloading - both are important in functional programming. And let’s add encapsulation and implementation hiding to this list.

      The argument is that OOP makes the wrong abstractions. Inheritance (as OOP models it) is quite rare on business entities. The other major example cited is that an algorithm written in the OOP style ends up distributing its code across the different classes, and therefore

      1. It is difficult to understand: the developer has to open two, three or more different classes to view the whole algorithm
      2. It is inefficient: because the algorithm is distributed over many classes and instances, as the algorithm runs, there are a lot of unnecessary calls (eg one method on one instance has to iterate over many instances of its children, and each child has to iterate over its children) and data has to pass through these function calls.

      Instead of this, the functional programmer says, you should write the algorithm as a function (or several functions) in one place, so it’s the function that walks the object structure. The navigation is done using tools like apply or map rather than a loop in a method on the parent instance.

      A key insight in this approach is that the way an algorithm walks the data structure is the responsibility of the algorithm rather than a responsibility that is shared across many classes and subclasses.

      In general, I think this is a valid point - when you are writing algorithms over the whole dataset. OOP does have some counterpoints encapsulating behaviour on just that object for example validating the object’s private members, or data processing for that object and its immediate children or peers.

    • masterspace@lemmy.ca
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      30 days ago

      Because an object is good at representing a noun, not a verb, and when expressing logical flows and concepts, despite what Java will tell you, not everything is in fact, a noun.

      I.e. in OOP languages that do not support functional programming as first class (like Java), you end up with a ton of overhead and unnecessary complications and objects named like generatorFactoryServiceCreatorFactory because the language forces you to creat a noun (object) to take an action rather than just create a verb (function) and pass that around.

      • CapeWearingAeroplane@sopuli.xyz
        link
        fedilink
        arrow-up
        0
        ·
        30 days ago

        This makes sense to me, thanks! I primarily use Python, C++ and some Fortran, so my typical programs / libraries aren’t really “pure” OOP in that sense.

        What I write is mostly various mathematical models, so as a rule of thumb, I’ll write a class to represent some model, which holds the model parameters and methods to operate on them. If I write generic functions (root solver, integration algorithm, etc.) those won’t be classes, because why would they be?

        It sounds to me like the issue here arises more from an “everything is a nail” type of problem than anything else.