4
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 02 Jul 2023
4 points (66.7% liked)
Functional Programming
1382 readers
1 users here now
founded 1 year ago
MODERATORS
Text summary?
I think the video description does a good job of summarizing it.
I asked ChatGPT to summarize from the video transcript:
"In the video, the presenter discusses a challenge in object-oriented programming related to changing the runtime type of objects. Using the example of invoices in a bookstore application, they demonstrate how the State design pattern is commonly used to address this issue but comes with limitations. They introduce the functional programming approach as an alternative, emphasizing the creation of types rather than classes and the use of abstract records and extension methods. The functional programming approach simplifies the implementation, avoids the need to change runtime types, and offers advantages such as shorter code. The presenter encourages viewers to consider adopting functional programming principles, especially with the evolving nature of languages like C#."
I'm not entirerely sure I agree with his premise. I totally see the merits of functional programming (either pure or blended with traditional OOP), but I don't think his example really solves the ORM problem any better than if he'd not used a deliberately contrived OOP example intended to make make his point look better.
As I understand, when you're working with an object-relational mapper (ORM), the default is to refer to persistent objects which cannot have their types changed at runtime. If an object goes through some kind of transformation, introducing new attributes, the best practice in OOP is to create a new object with those attributes so you don't leave nullable attributes in the original object's class definition. But this would cause the ORM to be unaware of your new object unless you create custom code to swap the references out, which is messy. In functional programming, you create a new object and DB reference by default, so no custom code is needed.
Alternately, in OOP, you could create smaller objects to contain the attributes which are expected to change through the lifetime of the controlling object, and give the outer object an attribute which refers to the smaller object. This way, the contained object may change entirely, but the owner object's type remains static in the ORM and always has a non-nullable attribute pointing to the mutable attributes (contained in objects which are swapped out functionally). It still means you have to tell the ORM when the smaller objects are swapped out, which is still messy, but at least it standardizes the process. That's my understanding of this issue, in any case.