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.
"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.
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.
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.
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.
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.
You're probably right. But they most likely know more about functional programming, logic programming (if they studied CS), and have some awareness of advanced concepts that generally weren't widely known when we were young.
I think it's just a shift in how development works: epicycles and all that. Luckily most OOP stuff they need to know can be taught quite quickly. And perhaps not knowing about GoF is a minor win for cyclomatic complexity in your codebase :-)
If you're a Typescript developer doing React you're probably not going to reach for classes, for example, as it's just not a common paradigm in most modern React/TS codebases.
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.
> 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.
I'm sure there is some (very high) level of inherent project complexity where the massive number of abstractions and tools that Spring Boot gives you (and forces on you) actually starts turning into a net positive... And I'm also fairly sure that most projects don't quite break even, and would be better off with something more lightweight.
Well, I just wrote a comment that could be considered an "OOP hate". I was debating whether to do it.
The point is not to be snug about it. Functional programming (and monads) are actually simpler. You just need to resist the urge to "make it more understandable".
Abstract math doesn't have good analogies to the real world. By trying to make an analogy with the concrete ("monads are mappable") you lose simplicity.
Monads might be simple but it's easy to create confusing large stacks of monad transformers in the haskell world, At least I have found and can often become not the most pleasant to work with aliasing complex monad stacks and all the rest, It can really lose elegance. Some problems beautifully fit as Monads and single monad code can be nice indeed but a few transformers and you can end up with a lot of mess. I do think there is some things that functional programming paradigm struggles with like games programming and other things, I really do think OOP is a better choice for some problems.
That relates to another misunderstanding. These ideas like "everything is a function" or "everything is a category" are not there to help you understand complex system better.
They are supposed to help you build better foundations; the abstractions to better understand your complexity you need to build (or at least pick) yourself.
Good foundations then help you relate the abstractions. For example, the categoric dual of a product is a sum. We can apply it to relation (relational algebra), and we get that sum is data inheritance.
So that gives you understanding of how functions (foreign keys), product (relation) and sum (inheritance) fit together. This sometimes helps to build abstractions in a consistent way.
Oh, I agree. But there's value in people who set out to do things a certain way, even if that approach ends up not working well in the long term.
We're collectively shaking a lot of trees when we build frameworks, languages and tools. What works? What does not? What is the right level of abstraction? How much developer ergonomy do we want to sacrifice?
Sadly we only seem to know in hindsight what works well. But that is also how we learn and grow; it was just meant to be this way.
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!
Component is not a term out of the FP schoolbook. I am sorry to be making what smells like a true scottsman here, but you seem to be describing a React codebase since they call themselves functional with that Redux stuff, you think this is functional programming. A graph of "components" all talking amongst each other. Functional. Programming. Come one, man :)
What you are describing is OOP. Passing messages between identities over calling pure functions with values.
In the newer versions of React with Redux, the components are all pure functions and state is centralized and passed down into the components. IMO it's as close as a codebase can be to pure functional programming whilst still functioning.
> IMO it's as close as a codebase can be to pure functional programming whilst still functioning.
You know, people have put functioning codebases using pure functional programming languages like Haskell, Elm, Purescript, etc. I really don't see what in your opinion is too close to FP to work.
> 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.
Isn't one of the tenants of FP that nothing is mutable anywhere?
Correct, technically they pass copies of the state; which gets cloned at every component/module/function boundary. This protects you from 'spooky action at a distance' which is a real problem which can happen when mutable state is shared by different components but FP can introduce other issues related to passing around a lot of state which can become outdated as it traverses the many layers of spaghetti code.
ya ive seen the same but in OOP codebases, where the state is all distributed and incapsulated and it's just impossible to reason about how the entire system works because despite it's separation of responsibilities everything is still intrinsically coupled together. and then you have all sorts of hidden mutations and other shenanigans.
to me the best way to design large systems is sort of like an ecs. you don't separate components by state + behaviour, you separate systems and state.
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.
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.
> “That's because I thought it made sense to represent a book as a sequence of Unicode code points stored along with the cumulative lengths of the individual fields. But you don't have to worry about it, since the auxiliary functions book_xxx are the ones that represent the interface that users should interact with.”
I’m not saying you should ever fire a coworker out of a cannon. I’m just saying that I wouldn’t always hold it against you.
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?
Well, what I don't understand is the SW engineering propensity towards cargo culting and doing things the harder way than mathematicians do.
I see it with OOP, XML, design patterns, and other things, now with LLMs. (LLMs - you really want to build complex systems in badly specified natural language, compiled or interpreted with an inscrutable algorithm and possibly indeterministic?)
Is it the excitement from a new analogy? Or are engineers naturally empiricists, while the rationalism/empiricism distinction doesn't work in computer science?
I think we would be better off if we just learned functional programming and few abstract concepts (categories, monads). Simpler than OOP.
But functional programming and OOP are intrinsically the same, but expressed using different primitives.
The thing that empowers first-class functions and closures (lexical binding) is the exact same method by which encapsulation works, even if the latter opts for heap vs stack. The fundamentals are the same.
Here's a simple one in Emacs Lisp:
(defmacro send (object method &rest args)
"Sends a METHOD to an OBJECT with ARGS."
`(funcall ,object ',method ,@args))
(defun make-animal (name)
;; 'hunger' is entirely private (encapsulated)
(let ((hunger 5))
;; here's our lambda using lexical binding
(lambda (method &rest args)
(cond
((eq method 'get-name) name)
((eq method 'feed)
(setq hunger (max 0 (1- hunger)))
"Yum!")
(t (error "Animal does not understand: %s" method))))))
(let ((good-boy (make-animal "Rex")))
;; "call" (via our macro) the "get-name" method; then feed. hunger does down 1.
(send good-boy get-name)
(send good-boy feed)
;; pretty-print the "object" good-boy
(pp good-boy))
;; this is the state of it after the two calls.
#[(method &rest args)
((cond ((eq method 'get-name) name)
((eq method 'feed) (setq hunger (max 0 (1- hunger))) "Yum!")
(t (error "Animal does not understand: %s" method))))
((hunger . 4) (name . "Rex"))]
Yes, you can express everything using lambda calculus. Kinda.. so why not use a thing that already exists? Why invent a new language (encapsulation) when previous (binding) suffices?
OOP is not about doing things harder, it‘s about doing them efficiently. The key elements of software engineering are abstraction and encapsulation: we, humans, cannot load the entire domain into our memory and reason about it at all levels of detail at once. We need to zoom in and zoom out, decompose problems into smaller pieces, then reassemble, treating those pieces at surface value. OOP isn‘t rocket science, it just adds one more piece — the hierarchy of concepts with inheritance and polymorphism. And it‘s just a technique: most programs are written in a mix of styles anyway. The foundational style is procedural, because that‘s how computers work. FP and OOP just build on top of it and translate to it.
> If you think you already know OOP, this article will change the way you think about programming
No, it won't. I'm especially sad that this, like so many OOP guides before it, did not go into how it interacts with data structures and bigger picture stuff. It had the perfect chance to do that as it could have made a Catalog class and then had a discussion about what belongs to that and what to the books. Instead it started to abstract on author, in the stupidest way possible (no, no one will ever look up a book using the author birth date).
OOP, like most stuff discussed in dev-related web, exists so that permaonline people can have another reason to create their own tribes and fight each other.
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"
OOP exists to add a quadrillion of layers to otherwise perfectly understandable business code in an attempt to obfuscate meaning and intent and guard against malicious extraction of valuable trade secrets.
Oh, it also helps me to pay my bills, because someone has to untangle the mess.
And it helps my therapist, because he has to keep the madness that grows inside of me in check.
Jokes aside: I was taught OOP at university.
I was also taught functional programming, answer set programming and other forms such as logical programming.
Focus was definitely on OOP though.
I mainly see OOP as a way to (dis) organizer code and a way for hardware manufacturers to sell more hardware.
OOP is sold on the promise that everything is modular. Since everything is neatly encapsulated with clearly defined API surfaces, you can easily swap out any part for any other. This should make developers interchangeable, because anyone can go in to the code and swap out parts as needed.
In reality this seems to make coupling even worse. Now you have to dig 8 classes deep just to find the business logic for a particular feature. Changing it is even harder because the rest of the program expects this part to behave in a very specific way.
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.
"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.
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.
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.
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.
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.
You're probably right. But they most likely know more about functional programming, logic programming (if they studied CS), and have some awareness of advanced concepts that generally weren't widely known when we were young.
I think it's just a shift in how development works: epicycles and all that. Luckily most OOP stuff they need to know can be taught quite quickly. And perhaps not knowing about GoF is a minor win for cyclomatic complexity in your codebase :-)
If you're a Typescript developer doing React you're probably not going to reach for classes, for example, as it's just not a common paradigm in most modern React/TS codebases.
I’ve met a lot of juniors who have no idea what functional programming is.
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.
> 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.
I'm sure there is some (very high) level of inherent project complexity where the massive number of abstractions and tools that Spring Boot gives you (and forces on you) actually starts turning into a net positive... And I'm also fairly sure that most projects don't quite break even, and would be better off with something more lightweight.
Well, I just wrote a comment that could be considered an "OOP hate". I was debating whether to do it.
The point is not to be snug about it. Functional programming (and monads) are actually simpler. You just need to resist the urge to "make it more understandable".
Abstract math doesn't have good analogies to the real world. By trying to make an analogy with the concrete ("monads are mappable") you lose simplicity.
Monads might be simple but it's easy to create confusing large stacks of monad transformers in the haskell world, At least I have found and can often become not the most pleasant to work with aliasing complex monad stacks and all the rest, It can really lose elegance. Some problems beautifully fit as Monads and single monad code can be nice indeed but a few transformers and you can end up with a lot of mess. I do think there is some things that functional programming paradigm struggles with like games programming and other things, I really do think OOP is a better choice for some problems.
In the end you will be passing messages between entities when your codebase becomes complex anough.
That relates to another misunderstanding. These ideas like "everything is a function" or "everything is a category" are not there to help you understand complex system better.
They are supposed to help you build better foundations; the abstractions to better understand your complexity you need to build (or at least pick) yourself.
Good foundations then help you relate the abstractions. For example, the categoric dual of a product is a sum. We can apply it to relation (relational algebra), and we get that sum is data inheritance.
So that gives you understanding of how functions (foreign keys), product (relation) and sum (inheritance) fit together. This sometimes helps to build abstractions in a consistent way.
Oh, I agree. But there's value in people who set out to do things a certain way, even if that approach ends up not working well in the long term.
We're collectively shaking a lot of trees when we build frameworks, languages and tools. What works? What does not? What is the right level of abstraction? How much developer ergonomy do we want to sacrifice?
Sadly we only seem to know in hindsight what works well. But that is also how we learn and grow; it was just meant to be this way.
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!
Component is not a term out of the FP schoolbook. I am sorry to be making what smells like a true scottsman here, but you seem to be describing a React codebase since they call themselves functional with that Redux stuff, you think this is functional programming. A graph of "components" all talking amongst each other. Functional. Programming. Come one, man :)
What you are describing is OOP. Passing messages between identities over calling pure functions with values.
In the newer versions of React with Redux, the components are all pure functions and state is centralized and passed down into the components. IMO it's as close as a codebase can be to pure functional programming whilst still functioning.
> IMO it's as close as a codebase can be to pure functional programming whilst still functioning.
You know, people have put functioning codebases using pure functional programming languages like Haskell, Elm, Purescript, etc. I really don't see what in your opinion is too close to FP to work.
> 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.
Isn't one of the tenants of FP that nothing is mutable anywhere?
Correct, technically they pass copies of the state; which gets cloned at every component/module/function boundary. This protects you from 'spooky action at a distance' which is a real problem which can happen when mutable state is shared by different components but FP can introduce other issues related to passing around a lot of state which can become outdated as it traverses the many layers of spaghetti code.
Don't forget to define OOP before requiring it!
ya ive seen the same but in OOP codebases, where the state is all distributed and incapsulated and it's just impossible to reason about how the entire system works because despite it's separation of responsibilities everything is still intrinsically coupled together. and then you have all sorts of hidden mutations and other shenanigans.
to me the best way to design large systems is sort of like an ecs. you don't separate components by state + behaviour, you separate systems and state.
I've seen some ugly OOP codebases, but I've seen some very nice ones too. I haven't seen any nice FP codebase yet besides basic APIs.
There's a reason why 99% of video games are OOP. That level of complexity is just too much for FP.
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.
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.
Compare and contrast https://www.youtube.com/watch?v=wo84LFzx5nI
> “That's because I thought it made sense to represent a book as a sequence of Unicode code points stored along with the cumulative lengths of the individual fields. But you don't have to worry about it, since the auxiliary functions book_xxx are the ones that represent the interface that users should interact with.”
I’m not saying you should ever fire a coworker out of a cannon. I’m just saying that I wouldn’t always hold it against you.
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)
OOP is fun if we could treat everything to be readily available in memory and retrievable infinitely fast.
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?
Someone learning programming it seems :D
Wayback link since the site was hugged to death: https://web.archive.org/web/20260827081007/mathspp.com/blog/...
Well, what I don't understand is the SW engineering propensity towards cargo culting and doing things the harder way than mathematicians do.
I see it with OOP, XML, design patterns, and other things, now with LLMs. (LLMs - you really want to build complex systems in badly specified natural language, compiled or interpreted with an inscrutable algorithm and possibly indeterministic?)
Is it the excitement from a new analogy? Or are engineers naturally empiricists, while the rationalism/empiricism distinction doesn't work in computer science?
I think we would be better off if we just learned functional programming and few abstract concepts (categories, monads). Simpler than OOP.
But functional programming and OOP are intrinsically the same, but expressed using different primitives.
The thing that empowers first-class functions and closures (lexical binding) is the exact same method by which encapsulation works, even if the latter opts for heap vs stack. The fundamentals are the same.
Here's a simple one in Emacs Lisp:
Yes, you can express everything using lambda calculus. Kinda.. so why not use a thing that already exists? Why invent a new language (encapsulation) when previous (binding) suffices?
OOP is not about doing things harder, it‘s about doing them efficiently. The key elements of software engineering are abstraction and encapsulation: we, humans, cannot load the entire domain into our memory and reason about it at all levels of detail at once. We need to zoom in and zoom out, decompose problems into smaller pieces, then reassemble, treating those pieces at surface value. OOP isn‘t rocket science, it just adds one more piece — the hierarchy of concepts with inheritance and polymorphism. And it‘s just a technique: most programs are written in a mix of styles anyway. The foundational style is procedural, because that‘s how computers work. FP and OOP just build on top of it and translate to it.
> If you think you already know OOP, this article will change the way you think about programming
No, it won't. I'm especially sad that this, like so many OOP guides before it, did not go into how it interacts with data structures and bigger picture stuff. It had the perfect chance to do that as it could have made a Catalog class and then had a discussion about what belongs to that and what to the books. Instead it started to abstract on author, in the stupidest way possible (no, no one will ever look up a book using the author birth date).
The older I get the more I realize the stuff I learned in university was just plain wrong.
It's incredibly difficult now dealing with zoomers in the workplace that think I'm some old boomer that never learned "proper computer science".
No, sorry Timmy, it's not because I don't understand microservices, it's because I actually do.
Well did you learn proper computer science or did you learn plain wrong computer science?
A good book for appreciating the OO mindset is Object Thinking by David West.
This seems like a beginner-level OOP-in-Python tutorial, and I'm disappointed the author didn't demonstrate a functional abstraction for `find_by`.
There is good OOP, there is bad OOP, and then there is PHP(OOP).
Site died.
OOP, like most stuff discussed in dev-related web, exists so that permaonline people can have another reason to create their own tribes and fight each other.
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.
Does not need classes.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.
Nah even traits are kinda bad because it increases the indirection necessary for code reading
OOP exists to add a quadrillion of layers to otherwise perfectly understandable business code in an attempt to obfuscate meaning and intent and guard against malicious extraction of valuable trade secrets.
Oh, it also helps me to pay my bills, because someone has to untangle the mess.
And it helps my therapist, because he has to keep the madness that grows inside of me in check.
Jokes aside: I was taught OOP at university.
I was also taught functional programming, answer set programming and other forms such as logical programming.
Focus was definitely on OOP though.
I mainly see OOP as a way to (dis) organizer code and a way for hardware manufacturers to sell more hardware.
OOP is sold on the promise that everything is modular. Since everything is neatly encapsulated with clearly defined API surfaces, you can easily swap out any part for any other. This should make developers interchangeable, because anyone can go in to the code and swap out parts as needed.
In reality this seems to make coupling even worse. Now you have to dig 8 classes deep just to find the business logic for a particular feature. Changing it is even harder because the rest of the program expects this part to behave in a very specific way.