this post was submitted on 02 Jul 2023
9 points (68.0% liked)
C Sharp
1508 readers
1 users here now
A community about the C# programming language
Getting started
Useful resources
- C# documentation
- C# Language Reference
- C# Programming Guide
- C# Coding Conventions
- .NET Framework Reference Source Code
IDEs and code editors
- Visual Studio (Windows/Mac)
- Rider (Windows/Mac/Linux)
- Visual Studio Code (Windows/Mac/Linux)
Tools
Rules
- Rule 1: Follow Lemmy rules
- Rule 2: Be excellent to each other, no hostility towards users for any reason
- Rule 3: No spam of tools/companies/advertisements
Related communities
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.