I think this discrbes a technique I use with json data. I read the json into the library's generic storage, then define types which pull out the data of interest, using the libraries object conversion. It is kind of like network masking where the IP address does not change but I'm only going to look at...
@viebel
The only online references I found on "data oriented programming" are yours :-)
The problem I see with this design is that it seems like just another tradeoff. You trade classes for schema validators. You design immutable structures to mitigate errors and sacrifice performance, as every mutation creates a copy of the previous data.
It reminds me of what happens on every REST API request - you map the xml/json to arrays/objects, then validate the schema, then do stuff with the validated data. I usually map it to internal data structures (DTOs) or ORM classes, depending on use-case. I can't really imagine how I write a schema+validator for every part of my application, every service interacting with the data (services, controllers, background jobs, etc.). I can see flexibility, but I can't see the reduction in complexity mentioned.
Could you point me to some sample code? Prefereably something heavier than a hello-world app.
Also, I can see you mention the paradigm is language-agnostic, but which language do you think would benefit most? (Seeing the tags in this article, would it be Java or JavaScript?)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The DOP approach is to decouple schema validation from data typing.
In other words:
The developer is then free to decide what pieces of data should have a schema and what functions should validate their input.
I think this discrbes a technique I use with json data. I read the json into the library's generic storage, then define types which pull out the data of interest, using the libraries object conversion. It is kind of like network masking where the IP address does not change but I'm only going to look at...
@viebel The only online references I found on "data oriented programming" are yours :-)
The problem I see with this design is that it seems like just another tradeoff. You trade classes for schema validators. You design immutable structures to mitigate errors and sacrifice performance, as every mutation creates a copy of the previous data.
It reminds me of what happens on every REST API request - you map the xml/json to arrays/objects, then validate the schema, then do stuff with the validated data. I usually map it to internal data structures (DTOs) or ORM classes, depending on use-case. I can't really imagine how I write a schema+validator for every part of my application, every service interacting with the data (services, controllers, background jobs, etc.). I can see flexibility, but I can't see the reduction in complexity mentioned.
Could you point me to some sample code? Prefereably something heavier than a hello-world app.
Also, I can see you mention the paradigm is language-agnostic, but which language do you think would benefit most? (Seeing the tags in this article, would it be Java or JavaScript?)