Hey,
Hmm, this causes some other design issues. We will have a SnakSerializer
which has to take a $dataValueSerializer. Of course we
should not specify a
concrete type because of flexibility, but a problem of this solution is
that wrong Serializers that cannot handle DataValues will only throw an
exception at runtime but do not show a warning when "compiling". Do you
have any suggestions how we can avoid those issues?
Good observation. This, a decrease in type safety, is a typical trade-off
one makes when creating boundaries. This means the code constructing a
SnakSerializer is responsible for making sure it is feeding in a Serializer
implementation that can serialize data values. A small price to pay for the
decoupling and flexibility gained.
Also note that not a lot of code should be constructing these service
objects, and know about the dependencies. In fact, this likely should only
be done in one place, which is a factory provided by the library. An
example of this can be seen here:
https://github.com/wmde/AskSerialization/blob/master/src/Ask/DeserializerFa…
Another important thing to realize is that if one writes the right
component and integration tests, any incorrect wiring up of the serializes
will be found.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--