...
Review existing unit tests and system tests.
Rejected Alternatives
...
The code examples here are made with the Deserializer
class but they are completely valid for the Serializer
as well.
Propagate to more complicated
We could propagate the method calls to the deserialize(String,Headers,byte[])
method. The drawback here is that it wouldn't be backward compatible as the ExtendedDeserializer just did the opposite thing: it propagated the deserialize(String,byte[])
method from the deserialize(String,Headers,byte[])
method.
Code Block | ||||
---|---|---|---|---|
| ||||
public interface Deserializer<T> extends Closeable {
default T deserialize(String topic, byte[] data) {
return deserialize(topic, null, data);
}
default T deserialize(String topic, Headers headers, byte[] data) {
return null;
}
} |
Headers as parameter
In this version we'd make sure that setHeaders
is called right before deserialize
(or the same goes for serialize
). The drawback of this is that we'd force implementations to maintain state.
Code Block | ||||
---|---|---|---|---|
| ||||
public interface Deserializer<T> extends Closeable {
void setHeaders(Headers headers);
default T deserialize(String topic, byte[] data) {
return null;
}
} |
Circular-referencing methods
This implementation is pretty good if the user overrides one (or both) the methods, however in the case where the default implementation is used for both of them, we'll get into a circular method reference and eventually a stack overflow.
Code Block | ||||
---|---|---|---|---|
| ||||
public interface Deserializer<T> extends Closeable {
default T deserialize(String topic, byte[] data) {
return deserialize(topic, null, data);
}
default T deserialize(String topic, Headers headers, byte[] data) {
return deserialize(topic, data);
}
} |