So I see some rants hating on OOP here. Lemme get the record straight: OOP is trash without SOLID principles. They're like husband and wife, Mass and Divine Office, developer and rubber ducky, cat and catnip. Car and garage. DuoLingo and push notifications.

For example, without the Liskov Substitution Principle, you'd have this god abstract class that has lots of abstract methods, some of those methods will only be used by other classes (as in filled with subclass-specific code) and remained unused by the others.

Without Dependency Inversion, your classes would be chock full of dependencies invoked at property level and you find yourself repeating the initializations of the same dependencies across classes.

SOLID is OOP's inner mainstay. Without SOLID, your OOP codebase would be this beast you have to feed that grows ever increasingly violent. You have a beef with OOP, fine. But I think it's unreasonable for a developer to hate on OOP if they do not implement some SOLID principles on top of it at first.

  • 4
    People tend to hate things they have no capacity to master :) except for Liferay. Everybody hates Liferay.
  • 2
    @netikras I've only heard of Liferay just now and I hate him! 😡
  • 3
    @jennytengsonM See? Everybody hates Liferay...

    A pro tip: if you are ever asked to consider Liferay for the project -- immediately answer NO.

    If you are ever recruited for a Liferay project -- RUN.

    Unless ofc you have some solid discounts for painkillers, as you will have lots of horrible headaches for sure.
  • 2
    When Alan Kay coined the term OOP, it had nothing to do with glorified structs containing function pointers. It was about actors passing messages, which is a much more powerful idea that is fully possible even in a procedural implementation.

    What we have as OOP today is a good fit when you actually have such objects in the problem domain, and that's the case for GUI and simulations (including many games).

    Especially when you end up with horrible nebulous ControllerManagerHandlerFactories that don't have any problem domain mapping, you know that's OOP gone wrong.
  • 4
    > this god abstract class that has lots of abstract methods, some of those methods will only be used by other classes

    This. Inheritance is not a copy-paste replacement, but gets misused for that all the time. Suddenly there's an inheritance hierarchy four or more layers deep, of which you have to know everything to understand what the leaf classes actually do. And then the requirements change sligthly and nullify a basic assumption of a base class. The resulting refactoring is *cough* such fun *cough*.

    Inheritance is maybe the strongest relation between two pieces of code. Don't use it unless you have a good reason.
  • 1
    OOP will never beat functional programming period.

    We live in distributed, multitasking, asynchronous world that is mostly not object oriented.
  • 2
    We also live in a world, where people still think that OOP and FP are polar opposites, because they never took the time to actually learn about paradigms and instead, just quote medium articles.
  • 4
    @vane That's overrated. FP bans mutable state and is hailed for concurrent programming.

    The downsides are that not only accidental, but also intentional sharing of mutable state goes out of the window. On top of that, you now have to deal with stale state instead of concurrent state, which is not really easier.

    FP is suited when it's about computing results like in math functions, but not when it's exactly about state or behaviour (which a lot of code is).
  • 1
    @Fast-Nop well for basic programs that need to get data and display something it’s not that bad. Those programs are probably 90% of all software and mostly what you do is display objects so easiest way is to get objects.

    I don’t deny that there are no use cases for OOP, my point is that OOP is ok for displaying something simple.

    For processing data when you want to know what is input and what is output functional programming shines.

    For me displaying is like the last step. Maybe most important from business perspective but least important from architectural one.
  • 0
    @metamourge and in the world where oop languages are introducing functional paradigms that makes modern code base mish mash so ugly when I look at it I want to puke
  • 3
    @vane OOP is also fine for simulations and games where you have a lot of different instances of the same things (particles, NPCs) with similiar behaviour but each different data.

    But I think we do have a fair arena where all paradigms can be tried, and it should favour FP because it's about computing stuff. So why is there no competetive chess engine in Haskell?

    The first three project hits in Google were:
    1+2) Abandoned before even implementing the rules completely
    3) Knows the rules, but plays so weak that I had no trouble mating it in 19 moves.
  • 1
    Maybe cause it’s easier to start writing oop then functional code but it doesn’t mean oop is better cause it’s easier.

    It’s like writing javascript is best language cause you only need a browser to run it.

    For me I write better software since I know functional language but maybe it’s just me that I understand things better by learning some stupid erlang or clojure.

    Now when I deal with graph structures recurrence is not a challenge.

    I still wonder how the fuck people write oop code without knowing what design patterns are. They use RX shit cause they don’t understand actors or observers. They use flux in react cause they don’t understand memento and command. Those are simple things like data structures yet nobody cares. Best part is some of those patterns like actor are from 70s and now mainstream is like wow it’s awesome.

    I am like WTF people programming doesn’t end on learning for loop.

    On the other hand you can’t write functional software without knowing what recurrence is, you will make less mistakes and when your code compile it’s 99% chance it works. That’s what it is about for me.
Add Comment