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/DeserializerFactory.php

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.


Jeroen De Dauw
Don't panic. Don't be evil. ~=[,,_,,]:3