OOP is just Named FP

I spent a long time dissecting OOP and I had a really interesting realization that I detailed in the attached blog post. If you're as interested in software design as I am, I hope you get new inspiration for how to structure your programs from it. I'm obviously leaving out a lot, but if you're intuitively familiar with the concepts behind OOP, you should understand the parts I left implied. PS for after you read it: Now obviously, I'm not saying they're "the same thing". There are different styles of programming that make something "more functional" or "more object-oriented". In fact, the "pure" versions of both OOP and FP are extremely easy to identify: pure OOP being the endpoint of leaning into the naming, and pure FP being the endpoint of leaning into the functors, and neither really being fun to work with. But my point is that the fundamentals of both are the same, just like how derivatives and integrals form two sides of Calculus. If you try to defend one and chastise the other, you can't use either effectively, and just dig yourself deeper into a hole of design patterns to make up for how inflexible you've left yourself. In truth, once we dissect how OOP really works, we can deconstruct it to replace most design patterns with something that borrows from each of them - Factories with constructor references, listeners with function references, list mapping with transducers - all without violating any OOP principles. It's only once we intuitively understand their foundations that we can use OOP less rigidly and FP more structured, creating something that's far greater than the sum of its parts. submitted by /u/bythepowerofscience [link] [留言]