Ah, crap I should have posted this mail to the Kerby mailing list... Will do that starting from now.
Le 24/12/15 14:07, Zheng, Kai a écrit : > Nice comments! Let me focus on something to explain. > > Regarding merge AbstractAsn1Type and Asn1Encodeable. As I said before, the > former wraps a Java value, the latter does the encoding/decoding dirty work. > The separation may does no good so far, but would also do no hurt for the > left. Something may start with the latter and doesn't like the generic thing. > How about if we make the parser results encodeable/decodeable? On other Java > platform that doesn't support the generic thing very well? How about if we > bridge this library to other ASN1 stuffs? Yes as you said these are just > maybe, uncertain things. But if the merging doesn't generate some good for > now, I thought it may be not bad to go the way. > > I guess you're mentioning two approaches: either let the ASN1 objects do > encode/decode themselves, or have some help class to delegate the dirty work > out. Yeah this is an architecture decision that's done when coming up the > first piece of the codes. I remembered I tried many times, but never got a > way that works perfect in every aspect. We used the former approach that goes > not bad so far if we don't attempt to support many other coding rules and do > BER/DER as good as possible. I see. It would be a real pain to have a class having a encodeBer(), encodeDer(), encodeWTFer()... methods into it. May I suggest a third approach ? The Visitor pattern might be a good candidate here : https://en.wikipedia.org/wiki/Visitor_pattern The idea is to delegate the encoding to a visitor, that will use the right encoding type. We decouple the encoding/decoding from the value classes. It adds a bit of complexity, but in our case, this might be the correct approach.
