directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [LDAP] [Codec] Using decorators instead of factories
Date Sun, 23 Jan 2011 23:58:20 GMT
On Mon, Jan 24, 2011 at 1:42 AM, Emmanuel Lecharny <> 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 ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message