Why OOP Exists: A Clear Explanation with a Real-World Example
This article explains the core ideas behind object-oriented programming (OOP) by telling the story of a college project where the author and his friend Tito build a library management system. It shows how OOP helps represent real-world entities like books and authors, hide implementation details, and organize related functions. The article also introduces Python classes as namespaces for grouping functions, making OOP accessible even to beginners.
The core idea of OOP is that you create high-level abstractions for the entities that you care about to make it easier to work with them.
- reaanb2
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.
- mickeyp
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.
- mrkeen
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)
- eru
Compare and contrast https://www.youtube.com/watch?v=wo84LFzx5nI
- tarix29
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.