Download the source code for this demo at Patreon: https://www.patreon.com/posts/one-thing-you-do-85222122In Object-Oriented Programming, objects are instanc...
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.
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.