Adapter vs Abstract classes

[Emmanuel Lecharny <el...@gmail.com>]

Hi guys,

while looking at the filters, I found a class name IoFilterAdapter. The 
javadoc says that this is an abstract class (but the class is _not_ 
avstract ;).

So I have done some research in the code, and I found that we are using 
either AbstractXXX.java classes and XXXAdapter.java classes. I think 
this should be normalized in order to always use the same prefix or 
postfix.

A quick grep gives :
/mina/trunk$ find . -name "*Adapter*" | grep -v .svn | grep -v target
./core/src/main/java/org/apache/mina/core/service/IoHandlerAdapter.java
./core/src/main/java/org/apache/mina/core/filterchain/IoFilterAdapter.java
./core/src/main/java/org/apache/mina/filter/codec/demux/MessageDecoderAdapter.java
./core/src/main/java/org/apache/mina/filter/codec/ProtocolDecoderAdapter.java
./core/src/main/java/org/apache/mina/filter/codec/ProtocolEncoderAdapter.java
./core/src/main/java/org/apache/mina/handler/multiton/SingleSessionIoHandlerAdapter.java

and for Abstract classes :
/mina/trunk$ find . -name "Abstract*" | grep -v .svn | grep -v target
./core/src/main/java/org/apache/mina/core/service/AbstractIoService.java
./core/src/main/java/org/apache/mina/core/service/AbstractIoConnector.java
./core/src/main/java/org/apache/mina/core/service/AbstractIoAcceptor.java
./core/src/main/java/org/apache/mina/core/session/AbstractIoSessionConfig.java
./core/src/main/java/org/apache/mina/core/session/AbstractIoSession.java
./core/src/main/java/org/apache/mina/core/buffer/AbstractIoBuffer.java
./core/src/main/java/org/apache/mina/core/polling/AbstractPollingIoProcessor.java
./core/src/main/java/org/apache/mina/core/polling/AbstractPollingIoAcceptor.java
./core/src/main/java/org/apache/mina/core/polling/AbstractPollingIoConnector.java
./core/src/main/java/org/apache/mina/core/polling/AbstractPollingConnectionlessIoAcceptor.java
./core/src/main/java/org/apache/mina/util/byteaccess/AbstractByteArray.java
./core/src/main/java/org/apache/mina/transport/socket/AbstractSocketSessionConfig.java
./core/src/main/java/org/apache/mina/transport/socket/AbstractDatagramSessionConfig.java
./core/src/main/java/org/apache/mina/proxy/AbstractProxyLogicHandler.java
./core/src/main/java/org/apache/mina/proxy/AbstractProxyIoHandler.java
./core/src/main/java/org/apache/mina/proxy/handlers/http/AbstractHttpLogicHandler.java
./core/src/main/java/org/apache/mina/proxy/handlers/http/AbstractAuthLogicHandler.java
./core/src/main/java/org/apache/mina/proxy/handlers/socks/AbstractSocksLogicHandler.java
./core/src/main/java/org/apache/mina/filter/codec/AbstractProtocolDecoderOutput.java
./core/src/main/java/org/apache/mina/filter/codec/AbstractProtocolEncoderOutput.java
./core/src/main/java/org/apache/mina/filter/stream/AbstractStreamWriteFilter.java
./core/src/test/java/org/apache/mina/transport/AbstractFileRegionTest.java
./core/src/test/java/org/apache/mina/transport/AbstractTrafficControlTest.java
./core/src/test/java/org/apache/mina/transport/AbstractBindTest.java
./core/src/test/java/org/apache/mina/transport/AbstractConnectorTest.java
./core/src/test/java/org/apache/mina/filter/stream/AbstractStreamWriteFilterTest.java
./integration-beans/src/main/java/org/apache/mina/integration/beans/AbstractPropertyEditor.java
./statemachine/src/main/java/org/apache/mina/statemachine/context/AbstractStateContextLookup.java
./statemachine/src/main/java/org/apache/mina/statemachine/context/AbstractStateContext.java
./statemachine/src/main/java/org/apache/mina/statemachine/transition/AbstractTransition.java
./statemachine/src/test/java/org/apache/mina/statemachine/context/AbstractStateContextLookupTest.java
./integration-ognl/src/main/java/org/apache/mina/integration/ognl/AbstractPropertyAccessor.java
./example/src/main/java/org/apache/mina/example/proxy/AbstractProxyIoHandler.java
./example/src/main/java/org/apache/mina/example/sumup/codec/AbstractMessageEncoder.java
./example/src/main/java/org/apache/mina/example/sumup/codec/AbstractMessageDecoder.java
./example/src/main/java/org/apache/mina/example/sumup/message/AbstractMessage.java
./example/src/test/java/org/apache/mina/example/echoserver/AbstractTest.java

So I think we should rename the 6 classes using an Adapter postfix to 
make them use Abstract prefix, for the sake of uniformity.

Any objection ?

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Adapter vs Abstract classes

[Emmanuel Lecharny <el...@gmail.com>]

Maarten Bosteels wrote:
> I fully agree with Christian.
>   
Even with the fact that wahat we call 'Adapter' are absolutly not adpaters ?

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Adapter vs Abstract classes

[Emmanuel Lecharny <el...@gmail.com>]

Tuure Laurinolli wrote:
> Christian Migowski wrote:
>
>> An adapter is something your application can... adapt :)
>
> No, that would be an adaptable. Adapter is something that adapts a 
> thing, i.e. your application in the above.
>
> In MINA adapters the adaptation target is implicit, and adaptation 
> happens through the inheritance mechanism. I found the name somewhat 
> confusing at first too. Partially because there is no explicit, 
> separately addressable adaptable.

Ahha ! I'm not alone, then :)


-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Adapter vs Abstract classes

[Tuure Laurinolli <tu...@indagon.com>]

Christian Migowski wrote:

> An adapter is something your application can... adapt :)

No, that would be an adaptable. Adapter is something that adapts a 
thing, i.e. your application in the above.

In MINA adapters the adaptation target is implicit, and adaptation 
happens through the inheritance mechanism. I found the name somewhat 
confusing at first too. Partially because there is no explicit, 
separately addressable adaptable.

Re: Adapter vs Abstract classes

[Emmanuel Lecharny <el...@gmail.com>]

Christian Migowski wrote:
> 2008/8/28, Julien Vermillard <jv...@archean.fr>:
>   
>> Hi,
>>
>>     
>>> Ok, to be very clear : I don't want to start a debate or a flamewar
>>> about this, because it's really not important. It was just because I
>>> don't find it consistent to have 6 so called Adapters when everywhere
>>> in the code, we are using Abstract classes instead. I really wanted
>>> to know if there were some pretty good reasons to have followed a
>>> different patterns in those cases, something which is absolutely not
>>> an evidence when you look at the javadoc and at the implementation.
>>> That's it.
>>>       
>> Well here Abstract & Adapter are different, I start to think a lot of
>> Java programmer understand it as Christian. After checking there is a
>> lot of them in the JRE.
>>     
>
>
> This has nothing to do with being a java programmer (actually, i became one
> just one year ago, before i was messing long years with c/c++) but with
> common sense. it is nowhere written that you can't use a name that is used
> coincidently by a design pattern only if it implements this design pattern.
> An adapter is something your application can... adapt :)
>   
I'm just trying to stick with the semantic.
> I begin to think that Adapter means something horrible horrible in french.
>   
It depends on the body part you are thinking of ;)
> My, what a complete waste of time this thread is.
>   
Well, not that much. IMHO, it's much better to discuss such things on 
the ML than brutally commit the code, and wait for a reaction (which 
will certainly not come, as almost nobody is watching the commits ;)

And as far as we are moving toward a 2.0 RC, it's better to avoid 
committing code blindly, as it may break users' applications... Keep in 
mind that this is what makes it a community : we have different 
opinions, and it's _always_ better to express them (as soon as it does 
not become personal).

Ok, you didn't convinced me, but that does not mean I'm right :) This 
class won't be renamed.

Thanks !

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Adapter vs Abstract classes

[Christian Migowski <ch...@gmail.com>]

2008/8/28, Julien Vermillard <jv...@archean.fr>:
>
> Hi,
>
> > Ok, to be very clear : I don't want to start a debate or a flamewar
> > about this, because it's really not important. It was just because I
> > don't find it consistent to have 6 so called Adapters when everywhere
> > in the code, we are using Abstract classes instead. I really wanted
> > to know if there were some pretty good reasons to have followed a
> > different patterns in those cases, something which is absolutely not
> > an evidence when you look at the javadoc and at the implementation.
> > That's it.
>
> Well here Abstract & Adapter are different, I start to think a lot of
> Java programmer understand it as Christian. After checking there is a
> lot of them in the JRE.


This has nothing to do with being a java programmer (actually, i became one
just one year ago, before i was messing long years with c/c++) but with
common sense. it is nowhere written that you can't use a name that is used
coincidently by a design pattern only if it implements this design pattern.
An adapter is something your application can... adapt :)
I begin to think that Adapter means something horrible horrible in french.
My, what a complete waste of time this thread is.

regards,
christian


>
> > > You may after all want to instantiate a NOOP instance for whatever
> > > reason.
> > Very true. But it has to be something you have to need, too.
> > Otherwise, if it's only for the beauty of instanciating NOOP objects,
> > well, it enters in the YAGNI category ... :)
> >
>
> Agreeing here, let's avoid the confusion and make them abstract, in no
> way it's concrete classes. Users will just make an anonymous instance
> for special cases described by Alex.
>
> Julien
>
>

Re: Adapter vs Abstract classes

[Emmanuel Lecharny <el...@gmail.com>]

Julien Vermillard wrote:
> Hi,
>
> On Wed, 27 Aug 2008 19:44:09 +0200
> Emmanuel Lecharny <el...@gmail.com> wrote:
>
>   
>> Alex Karasulu wrote:
>>     
>>> Pretty much agree myself but I don't think Adapters need to be
>>> abstract. 
>>>       
>> Again, these classes are _not_ adapters, wrt the definition of the 
>> adapter pattern. That's my point. And when the javadoc says that the 
>> class is abstract, I'm expecting to see an 'abstract' keyword. Or
>> maybe the javadoc is incorrect.
>>     
>
> Well it's not the only meaning of ..Adapter in Java, for example : 
> http://www.ryerson.ca/~dgrimsha/courses/cps840/adapter.html
> It's just dummy implementation to listener interface, mainly.
>   
maybe... I just don't really like the mismatch between the header where 
this class is being described as Abstract, when it's not, plus the fact 
that if this class is not abstract, it's just because we have used it 
into tests, in order to inject dummy filters into a chain. Not sure that 
it was intended... (IMHO, defining a NoopFilter would have been slightly 
better.)
> Personally I don't care much, but I think if it make some sense as
> Christian described (adapter for dummy iface implementation and
> abstract for base classes for implementation) keep it.
>   
Yep, it doesn't matter a lot. Again, I didn't want this to become a big 
debate, just wanted to have a kind of consistence in the project.


Anyway, seems like my idea is not shared, so fuck it :)

I will just fix the header, to remove the mention of this class being 
abstract.

Thanks a lot for your opinions !

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Adapter vs Abstract classes

[Julien Vermillard <jv...@archean.fr>]

Hi,

On Wed, 27 Aug 2008 19:44:09 +0200
Emmanuel Lecharny <el...@gmail.com> wrote:

> Alex Karasulu wrote:
> > Pretty much agree myself but I don't think Adapters need to be
> > abstract. 
> Again, these classes are _not_ adapters, wrt the definition of the 
> adapter pattern. That's my point. And when the javadoc says that the 
> class is abstract, I'm expecting to see an 'abstract' keyword. Or
> maybe the javadoc is incorrect.

Well it's not the only meaning of ..Adapter in Java, for example : 
http://www.ryerson.ca/~dgrimsha/courses/cps840/adapter.html
It's just dummy implementation to listener interface, mainly.

Personally I don't care much, but I think if it make some sense as
Christian described (adapter for dummy iface implementation and
abstract for base classes for implementation) keep it.

> 
> Ok, to be very clear : I don't want to start a debate or a flamewar 
> about this, because it's really not important. It was just because I 
> don't find it consistent to have 6 so called Adapters when everywhere
> in the code, we are using Abstract classes instead. I really wanted
> to know if there were some pretty good reasons to have followed a
> different patterns in those cases, something which is absolutely not
> an evidence when you look at the javadoc and at the implementation.
> That's it.

Well here Abstract & Adapter are different, I start to think a lot of
Java programmer understand it as Christian. After checking there is a
lot of them in the JRE. 

> 
> > You may after all want to instantiate a NOOP instance for whatever
> > reason. 
> Very true. But it has to be something you have to need, too.
> Otherwise, if it's only for the beauty of instanciating NOOP objects,
> well, it enters in the YAGNI category ... :)
> 

Agreeing here, let's avoid the confusion and make them abstract, in no
way it's concrete classes. Users will just make an anonymous instance
for special cases described by Alex.

Julien

Re: Adapter vs Abstract classes

[Emmanuel Lecharny <el...@gmail.com>]

Alex Karasulu wrote:
> Pretty much agree myself but I don't think Adapters need to be abstract.
>   
Again, these classes are _not_ adapters, wrt the definition of the 
adapter pattern. That's my point. And when the javadoc says that the 
class is abstract, I'm expecting to see an 'abstract' keyword. Or maybe 
the javadoc is incorrect.

Ok, to be very clear : I don't want to start a debate or a flamewar 
about this, because it's really not important. It was just because I 
don't find it consistent to have 6 so called Adapters when everywhere in 
the code, we are using Abstract classes instead. I really wanted to know 
if there were some pretty good reasons to have followed a different 
patterns in those cases, something which is absolutely not an evidence 
when you look at the javadoc and at the implementation. That's it.

> You may after all want to instantiate a NOOP instance for whatever reason.
>   
Very true. But it has to be something you have to need, too. Otherwise, 
if it's only for the beauty of instanciating NOOP objects, well, it 
enters in the YAGNI category ... :)

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Adapter vs Abstract classes

[Alex Karasulu <ak...@apache.org>]

Pretty much agree myself but I don't think Adapters need to be abstract.
You may after all want to instantiate a NOOP instance for whatever reason.

Alex

On Wed, Aug 27, 2008 at 12:35 PM, Maarten Bosteels
<mb...@gmail.com>wrote:

> I fully agree with Christian.
>
> regards,
> Maarten
>
> On Wed, Aug 27, 2008 at 4:27 PM, Christian Migowski
> <ch...@gmail.com> wrote:
> > 2008/8/27, Emmanuel Lecharny <el...@gmail.com>:
> >
> >> Hi guys,
> >>
> >> while looking at the filters, I found a class name IoFilterAdapter. The
> >> javadoc says that this is an abstract class (but the class is _not_
> avstract
> >> ;).
> >>
> >> So I have done some research in the code, and I found that we are using
> >> either AbstractXXX.java classes and XXXAdapter.java classes. I think
> this
> >> should be normalized in order to always use the same prefix or postfix.
> >
> >
> > I wouldn't do so. Even from only reading the Javadoc you can see they
> have
> > very distinct purposes:
> >
> > The *Adapter classes are convenience wrappers meant to be extended by the
> > user if he only wants to use a "subset" of the interfaces they implement.
> > Oh, and i use some of them and could imagine others as well, so it would
> be
> > an API breakage without a useful reason.
> >
> > The Abstract* classes are typical abstract classes providing common
> > functionality for Mina internal classes that "branch" later on to
> specific
> > implementations.
> >
> >
> > Applying a different naming scheme for the two purposes is logical and
> > useful - and should be in your "good documentation over everything"
> spirit.
> > The only thing i would change is to make all the adapter classes abstract
> > since they only implement "NOOP" actions for their purposes and are
> > therefore not very useful to instanciate from.
> >
> >
> > christian
> >
>

Re: Adapter vs Abstract classes

[Maarten Bosteels <mb...@gmail.com>]

I fully agree with Christian.

regards,
Maarten

On Wed, Aug 27, 2008 at 4:27 PM, Christian Migowski
<ch...@gmail.com> wrote:
> 2008/8/27, Emmanuel Lecharny <el...@gmail.com>:
>
>> Hi guys,
>>
>> while looking at the filters, I found a class name IoFilterAdapter. The
>> javadoc says that this is an abstract class (but the class is _not_ avstract
>> ;).
>>
>> So I have done some research in the code, and I found that we are using
>> either AbstractXXX.java classes and XXXAdapter.java classes. I think this
>> should be normalized in order to always use the same prefix or postfix.
>
>
> I wouldn't do so. Even from only reading the Javadoc you can see they have
> very distinct purposes:
>
> The *Adapter classes are convenience wrappers meant to be extended by the
> user if he only wants to use a "subset" of the interfaces they implement.
> Oh, and i use some of them and could imagine others as well, so it would be
> an API breakage without a useful reason.
>
> The Abstract* classes are typical abstract classes providing common
> functionality for Mina internal classes that "branch" later on to specific
> implementations.
>
>
> Applying a different naming scheme for the two purposes is logical and
> useful - and should be in your "good documentation over everything" spirit.
> The only thing i would change is to make all the adapter classes abstract
> since they only implement "NOOP" actions for their purposes and are
> therefore not very useful to instanciate from.
>
>
> christian
>

Re: Adapter vs Abstract classes

[Christian Migowski <ch...@gmail.com>]

2008/8/27, Emmanuel Lecharny <el...@gmail.com>:

> Hi guys,
>
> while looking at the filters, I found a class name IoFilterAdapter. The
> javadoc says that this is an abstract class (but the class is _not_ avstract
> ;).
>
> So I have done some research in the code, and I found that we are using
> either AbstractXXX.java classes and XXXAdapter.java classes. I think this
> should be normalized in order to always use the same prefix or postfix.


I wouldn't do so. Even from only reading the Javadoc you can see they have
very distinct purposes:

The *Adapter classes are convenience wrappers meant to be extended by the
user if he only wants to use a "subset" of the interfaces they implement.
Oh, and i use some of them and could imagine others as well, so it would be
an API breakage without a useful reason.

The Abstract* classes are typical abstract classes providing common
functionality for Mina internal classes that "branch" later on to specific
implementations.


Applying a different naming scheme for the two purposes is logical and
useful - and should be in your "good documentation over everything" spirit.
The only thing i would change is to make all the adapter classes abstract
since they only implement "NOOP" actions for their purposes and are
therefore not very useful to instanciate from.


christian