Functional Programming

I think the video description does a good job of summarizing it.

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.

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.