directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject [ADS 2.0] Naming convention ... again !
Date Mon, 04 Sep 2006 10:41:36 GMT
Hi band,

a question that has already been discussed many times by all the developpers
on earth, but again, I need a shared vision.

So : which convention should we use for interface names?

Here is the problem :

I have a BindRequest class which will be extended using the decorator
pattern to add toDSML, toPDU, fromDSML and fromPDU methods. I will have two
concrete decorators :
- BindRequestDsmlDecorator
- BindRequestAsn1Decorator
and of course an abstract class called BindRequestDecorator

This abstract class will contains a reference to a BindRequest object, and
will implements all the BindRequest objects methods.

At this point, the question arise : why don't we have a BindRequest
interface and a BindRequestImpl class? The BindRequest interface will be
implemented by the BindRequestImpl and BindRequestDecorator classes.

Good idea. But then I'm a little bit annoyed by the name BindRequestImpl. So
am I with the BindRequestDecorator which could have been
AbstractBindRequestDecorator, as we have AbstractMessage, AbstractRequest,
etc.

To be short :
Q1 : Should we add an 'I' in front on interface that are not obviously seen
as interfaces (like BindRequest : renamed to IBindRequest) (I mean to avoid
a collision between an interface name and a class name) ?
Q2 : Should we add an 'I' in front of *all* interfaces, breaking the JLS
rules ? (so Message will be renamed to IMessage, even if it's obvious that
Message cannot be a concrete class)
Q3 : Should we add 'Abstract' in front of abstract class ?
Q4 : if Q1 and Q2 is *NO !!!*, then which name should we use for class which
implements interface : ConcreteBindRequest, BindRequestImpl ?

Note that I do not want to start a flamwar, I just need your opinion in
order to have a consistant naming across the project.

Any opinion is welcomed.

Emmanuel

-- 
Cordialement,
Emmanuel L├ęcharny

Mime
View raw message