On Mon, Jan 24, 2011 at 1:42 AM, Emmanuel Lecharny <[email protected]> wrote: > On 1/24/11 12:05 AM, Alex Karasulu wrote: >> >> I noticed that we consolidated several different message >> implementations in the past by making the implementation expose some >> package friendly methods so the codec could leverage these methods >> while encoding to track sizes of buffers etc. >> >> This causes some issues. First it creates a direct dependency on the >> codec implementation. To solve this you'd have to use a message >> factory interface. Codec implementors then provide a factory >> implementation that returns message instances of their implementation >> classes. Currently this would be what we have to do to hide the codec >> internals. >> >> Another approach would have been to use containment with wrappers, >> (decorator pattern [0]). So basically the codec makes messages that >> wrap other messages yet have the fields and methods to handle the size >> calculations. Let me give a simple example using the ControlImpl [1] >> in the codec whose dependency I had to break inside of the LDIF >> package for example. You can extrapolate this to the various Message >> types we have like AddRequest etc because this is just another >> contained object in the model. Notice all the additional length >> calculations for encoding/decoding. This codec specific functionality >> can be added to an object implementing the Control interface by having >> this ControlImpl optionally wrap a Control object, then added the >> additional codec specific calculations. See the example >> CodecControlDecorator [2] I just committed. >> >> This way implementation classes can be provided, instead of interfaces >> (mentioning this since this was asked for in the past) and they can >> avoid having dependencies on the codec. I personally prefer interfaces >> here. >> >> If we don't use this pattern we'll need to use a factory to generate >> the message objects all throughout the code base. > > As the messages are exposed in the API, I think we have to hide the > implementation. The best approach, to me, seems to use decorator, as > proposed.
I will start applying the pattern. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
