Why OOP Exists

Join the discussion

• Hacker News
• And then you start adding some real world books that have some of the attributes missing or uncertain, have several authors, go by different titles or uses some kind of exotic notation to their titling, and this OOP structure kind of crumbles?
  by slovenlich
• Someone learning programming it seems :D
  by bronlund
• OOP is perfectly fine.

  Rigid class-based inheritance (especially multi-inheritance) is what sucks. This over-engineered complexity really only benefits things like window toolkits where you want super rigid modeling of widget types. But even that's a stretch.

  Traits do OOP the right way. Complete flexibility.

      Dog goes "woof"
      Cat goes "meow"
      Bird goes "tweet"
      And mouse goes "squeak"
  

  Does not need classes.
  by echelon
• Nah even traits are kinda bad because it increases the indirection necessary for code reading
  by dnautics
• Not sure if intentional, but I read it in Ylvis’ “What does the fox say?” and now I can’t get it out of my head, thank you very much.
  by garretraziel
• Sometimes or even quite often considering objects as records is reasonable approach. It has set of fields. And maybe functions helpful to manipulate these fields or even use them. Even more complicated things are just records.

  And then sometimes it is useful to extend these functionalities for specific special cases.

  Maybe OOP is often taught going too abstract. And trying to model wrong things. But thinking of it as grouping fields and then adding functions to manipulate or use those and things related to them is useful.

  by Ekaros
• Wayback link since the site was hugged to death: https://web.archive.org/web/20260827081007/mathspp.com/blog/...
  by groomlake
• The article feels a bit late since we have come full circle: OOP attempted to force natural language ontologies into deterministic code, while LLMs can now process natural language ontologies directly. Prose has become the source code humans write (or at least read), and model weights are the new compiler that extract objects (or functions) and relationships directly from a written specification to generate Python. OOP hasn't disappeared; it has finally been supplanted by the natural language it always tried to mimic.
  by seanmcdirmid
• Nothing in this article is even OOP-specific. You can do all of this with structs and static dispatch. The code in a language like Go or Zig that supports the dot-notation would look pretty similar too.
  by tarix29
• Compare and contrast https://www.youtube.com/watch?v=wo84LFzx5nI
  by eru
• Admittedly I read this pretty quickly, but this is just structs.

  The "behaviours" being modelled here were data access. Writing .name() instead of .name.

  You can save yourself the time of manually packing these structs by writing out a constructor in full. Which the article called "automatic".

  (You don't even need to write out the constructor for a struct in C99. Probably any other modern language too)

  by mrkeen
• > this is just structs.

  Yes. And structs are just bytes. Levels of abstractions don't do anything the underlying levels don't already do, they just give you means to express your intent in a clearer form.

  by teo_zero
• OOP is fine. Not using OOP is fine too if your architecture / design demands it.

  What people forget -- much like the design patterns in the gang of four book -- is that languages and frameworks evolve.

  A decorator pattern was a niche but useful abstraction in the 1990s. In Python today you can @decorate stuff just like that. It's evolution.

  The same holds for OOP. Encapsulation and co-located methods with the encapsulating slots was an incredibly powerful upgrade over basic structs. Now most languages have first-class functions and lexical scoping so you can build your own encapsulation that way.

  It's all good. Just use whatever fits best.

  by mickeyp
• I often have to teach basic OOP concepts to junior - mid level developers.

  Many who've entered the career in the last decade or so seem to have missed what I 'd consider to be quite a fundamental grounding.

  Not even advanced concepts from the gang of four book - though I have taught these too - but often just an un-awareness of OOP in general, even simple things like understanding encapsulation.

  Frameworks and languages do evolve, but never being taught basic things like encapsulating state or exposing dependencies seems an issue. Very differnt from my own time as a junior when this stuff was constantly hammered home.

  by hereonout2
• OOP hate is definitely a popular way to signal that you aren't just a "common grunt programmer". And there are personalities who have made it a big part of their appeal.

  But I also spent some time with modern Spring Boot, and I get where the hate is coming from. There is a lot of complexity that just doesn't seem necessary at all.

  by slopinthebag
• Some problems don't require OOP, but most large complex problems do, IMO.

  Most complex codebases I've seen which were pure Functional Programming were spaghetti code; unmaintainable.

  What I saw every single time was that the project was syncing a huge amount of state in a central place and then passing it through a large number of components and sub-components. The top level component basically had to have full awareness of everything going on inside the system in order to do its job and there were no separation of responsibilities because none of the components had sovereignty over the state they needed to do their job independently. It's just components micro-managing components all the way down.

  React with Redux is probably the best FP implementation I've seen thus far but even it is kind of a mess. I have nightmares about Redux Saga. The Redux Saga logo is literally a stylized drawing of entangled spaghetti.

  Had Redux + Saga been presented to people as part of React at the time it was introduced, React would probably not have become so popular. Because people would have understood that it creates too much unnecessary baggage which isn't worth it. React was used as a gateway drug to Redux which was itself a gateway drug for Saga! And what I observed in practice is that most React apps are glitchy AF; and those glitches are usually difficult to reproduce and fix, even if you know all the ins and outs of the framework!

  by jongjong
• I agree.

  I used to be OOP hater, but realized that it has it's place and some problems are OOP shaped and OOP is a wide range of techniques. I do think that python is a sloppy language and generally don't like it.

  Functional programming has it's place and I love it and is probably what my mind goes to the most, but often in Functional languages I find you can 'over fit' to a particular way of doing things, And with OOP your get more degrees of freedom with things you can do with a class and things can be modified easier, think sort of problems like a board game just as an example treating the pieces as an object can make it easier to modify any section of the logic of the game and add new pieces then the typical functional approach.

  by kodoman
• This article describes the OOP approach that leads to object-relational mapping, boilerplate code, database schema duplicated in code, navigational data access and the impedance mismatch. It defines OOP around data modeling and taxonomy, rather than around responsibilities. Principles such as "Tell, don't ask" and "Single responsibility" are just ignored. What responsibility does a book have in a library management system? It doesn't, it's just a subject of recorded facts, and a better approach would be to identify the behavioural components of the solution space, construct those as classes/objects, and let facts be encapsulated in or communicated between objects.
  by reaanb2
• Yes, OOP is hard to do right. It's not helped by examples and schools largely teaching from real world nouns. Most people in OOP languages are writing procedural code.

  For all these reasons I just skip it. I still use OOP languages, but I leave the OOD at the door.

  For what it's worth, you can get all that with plain old C. Declare structs up front. Allocate them all as pointers. The C file is the class, and has the actual definition of the structs.

  Strangely enough, in a sense, OOP languages makes it harder to do this than in C. Not that C doesn't have other flaws.

  by bcrosby95
• "Object thinking" by David West was eye opening about this back in the day. The gist is to model the objects not along the line of real world entities, but along the line of "behaviour" like you mention.
  by omnibrain