So I developed a serialization/deserialization framework for our deployment tool, which worked like this:
1.) You write a class that registers for the serialization of an artefact type and implement the serialize() function.
2.) You write a class that registers for the deserialization of the same artefact type and implement the deserialize() function.
And as examples I implemented a "file" type and a "table_row" type. Then I let my coworkers implement all the special cases (a file that needs post-processing after deployment for example).
I thought my architecture was great, because it was simple to understand (write 2 classes for each type) and it was closed for changes (no need to change "file" or "table_row"), but open for additions (copy "file" to "special_file" and change "special_file").
Or so I thought. I really should have explained my intentions better, because what the others implemented was:
1.) You write a class that serializes an artefact type into a "file" or a "table_row".
2.) You change "file" or "table_row" so that it can handle the new type.
So now I have a long deserialization functions with lots of if/then/else blocks. Well... in hindsight a better approach would have been:
1.) You write a class that registers for the serialization AND deserialization of an artefact type and implement the serialize() and deserialize() functions.
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.
Not writing a guide for my architecture.
So I developed a serialization/deserialization framework for our deployment tool, which worked like this:
And as examples I implemented a "file" type and a "table_row" type. Then I let my coworkers implement all the special cases (a file that needs post-processing after deployment for example).
I thought my architecture was great, because it was simple to understand (write 2 classes for each type) and it was closed for changes (no need to change "file" or "table_row"), but open for additions (copy "file" to "special_file" and change "special_file").
Or so I thought. I really should have explained my intentions better, because what the others implemented was:
So now I have a long deserialization functions with lots of if/then/else blocks. Well... in hindsight a better approach would have been: