- cross-posted to:
- functional_programming
- cross-posted to:
- functional_programming
You must log in or register to comment.
I shouldn’t have to watch so far into a video to see what the topic actually is.
Isn’t this an entire class of problems that’s avoidable by using strict DDD-style entities?
You don’t have the same “purists” OOP problems, you don’t have extension methods to get lost in, you don’t have publicly mutable state, and you have a clear surface area for state changes. And your ORM is happy.
Purists OOP has all sorts of issues, more procedural, pragmatic, approaches can alleviate that pain. And strict entities provide the same surface area as the functional approach, without concerns over breaking ORM tracking. With the added benefits of closely guarding local state.
Opinion time.
This is less “what you can’t do in OOP” and more “what you can’t do if you use OOP design as dogma” 🤔. Perhaps that’s an important distinction to make, depending on your viewership, but to me this feels like a solution looking for a contrived problem.
I agree that this is a solution looking for a problem. I still think the way he explores the limits of the language is food for thought. And the fact that this is at all possible makes C# a fun language to work with.
Oh definitely. I have some gripes with C# as a language that I wish for better. But it’s extremely flexible.
Kind of sucks that the source is locked away…
Would be a lot more convenient to read it when I don’t have the whereabouts to watch a video about it(env, data…etc).
Edit: Finally was able to get the whole thing to load, commented on my thoughts.
Creating new objects would confuse your ORM vs. Always create new objects? Well, you’ve convinced me.
If you just made copy constructors in the first example, the problem wouldn’t have existed. This is wholly contrived, and I feel dumber for having watched it.
Not even saying I like OOP, or that functional isn’t usually a better paradigm - but this was the goofiest argument I’ve seen for it.
Video description:
In Object-Oriented Programming, objects are instances of classes and they encapsulate behavior and state - that is what every textbook on OOP is teaching. However, there’s a subtle limitation in OOP when it comes to dealing with changes in the state of these objects. We often try to mitigate that limitation by applying the State design pattern, but that adds extra complexity and potential confusion to downstream components, especially when using Object-Relational Mappers (ORMs).
In this video, you will learn to recognize the fundamental limitation of Object-Oriented Programming and how Functional Programming (FP) offers an inverse perspective. Through immutability and transformations of values, FP tends to make state transitions explicit and predictable, leading to a more straightforward way of handling the issues that would otherwise be too large a burden for a corresponding object-oriented model. This requires a shift in thinking and can introduce its own challenges and learning curves. It is a fascinating topic, shedding light on the fundamental underpinnings of OOP and FP, and their practical implications in software development.
deleted by creator
