object-oriented-programming-antipattern

This article is a stub. You can help the IndieWeb wiki by expanding it.

The object-oriented-programming antipattern is the excessive / unnecessary use of object-oriented-programming (OOP) and OOP techniques when simple procedural functions would have sufficed, with less overhead, fewer files to navigate around, fewer indirections to follow while debugging, etc.

Articles and references

• cat -v harmful stuff: Object Oriented Programming is Inherently Harmful
• fake plt nerd girl ‏@morganastra “object orientation is an elaborate web of design traps with something that looks like a computation model woven between them as bait”
• All evidence points to OOP being bullshit

See Also

• architecture astronomy
• database-antipattern
• https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
• architecture astronomy
• https://phpthewrongway.com/
• Article describing some history and (bad) programming/corporate culture effects of OOP: https://web.archive.org/web/20121214131923/http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics
  • ""
• Criticism: many layers of class hierarchy (typical OOP practices) make code more opaque for inspection & debugging: https://chat.indieweb.org/dev/2023-06-23/1687483875593100
  • "I do remember trying to find the code that does the verification too, but it was so buried in many layers of class hierarchy that I couldn't find anything useful" @aaronpk June 23, 2023
• Humor: https://mastodon.world/@exchgr/110686507297491516 (and see replies too)
  • "who called it object oriented programming and not class struggle" @exchgr July 9, 2023
• Criticism: wastes too much time compared to actual utility (for both library creators/maintainers, and clients). OOP encourages lots of time to be spent (wasted) with setting up a ton of boilerplate files (naming is hard), classes (naming is hard), methods (naming is hard), hierarchy (information architecture is hard), when a flat set of functions would suffice for 90%+ of use-cases, and the best way to discover that other 10% is to start flat and then only add hierarchy when the flat set of things gets too large and you need some "chunking" to make it easier to navigate.