==== Question ====

Discuss the advantages and disadvantages of the class hierarchy in the previous
assignment. Focus on readability, scalability and/or usability: i.e. how easy is the code to
understand for the reader, how easy is the code to change and how easy are the classes
to use. Your answer should be around 300-1000 words. Give code examples. You don’t
have to cover all three aspects, but make sure to bring up at least one advantage and one
disadvantage.

==== Answer ====

To make a new type serializable we have to add a derived class for
that type. Right now we only support serializing integers and strings,
but it is possible to add a serialization class for a specific class
by simply inheriting from Serializable and overriding the virtual
functions "serialize" and "deserialize". This makes the code base
quite scalable.

However it is not easy to use since the user has to know before they
serialize or deserialize what type they need, and whether there is a
derived class for this type. For example: suppose I want to serialize
an integer x, then you would do this:

Integer serializer { x };
std::string serialized_integer = serializer.serialize();

Compare this to the much easier:

std::string serialized_integer = std::to_string(x);

Of course, we can imagine that there are more complicated types for
which there is no builtin std::to_string function, and then it would
be better.  But C++ itself has support for serialization and
deserialization with streams, meaning it is probably easier (and more
recognizable) to use operator<< and operator>> for these purposes.
Then we also have the added bonus of moving the responsibility of
making a type serializable to the author of that type (i.e. they have
to implement the stream operators). In that case all serialization
would look something like this (where obj is an object of some
arbitrary type that has the stream operators):

std::ostringstream oss { };
oss << obj;

And deserialization would look like this:

std::istringstream iss { str };
iss >> obj;

Here we don't have to worry about what the corresponding serialization
class is called or if it exists: the compiler tells us if this doesn't
work and then we know that we have to implement the operators, and
otherwise it will just work the same for all cases.

Because of this I would argue that this is quite a weak design since there
are better alternatives. However there might be case for arguing that
this type of construction:

My_Type_Serializer serializer { my_obj };
std::string serialized_integer = serializer.serialize();

Much better communicates what is going on, since here we explicitly
use the word "serialize" which tells the user a lot more than just seeing:

oss << my_obj;

So I argue that this code is much more readable for the user.