You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2006/09/04 12:41:36 UTC
[ADS 2.0] Naming convention ... again !
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
Re: [ADS 2.0] Naming convention ... again !
Posted by Ersin Er <er...@gmail.com>.
My preferences are:
Interfaces with expected common names: BindRequest
Abstract classes with Base prefix: BaseBindRequest
Concrete classes with either Default or Basic prefix:
DefaultBindRequest, BasicBindRequest
Abstract prefix is bad because of the same reasons of Impl suffix. And
Impl suffix is bad because of the mentioned reasons :-) Concrete
suffix is also similar, smells implementation..
Cheers,
On 9/5/06, Trustin Lee <tr...@gmail.com> wrote:
> Hi Emmanuel,
>
> On 9/4/06, Emmanuel Lecharny <el...@gmail.com> wrote:
> >
> > Hi band,
> >
> >
> > 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.
> >
>
> I agree. Providing BindRequest as an interface is a better approach.
>
> >
> > 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.
>
>
> I hate adding 'Impl' in the end of a class name. It makes me feel bad
> because:
>
> 1) I am abbreviating 'implementation'
> 2) It gives me an impression that it's the only implementation.
>
> So I'd rather suggest DefaultBindRequest or SimpleBindRequest. I prefer
> Default because Simple is a little bit vague.
>
>
> >
> > 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) ?
>
>
> -1
>
> >
> > 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)
>
>
> -1
>
> >
> > Q3 : Should we add 'Abstract' in front of abstract class ?
>
>
> It's not mandatory when the abstract class contains some meaningful
> implementation, and then it can have a different prefix. So... it depends
> on context, but adding Abstract is a safe option in most cases.
>
> >
> > Q4 : if Q1 and Q2 is *NO !!!*, then which name should we use for class
> which implements interface : ConcreteBindRequest, BindRequestImpl ?
>
>
> My suggestion is DefaultBindRequest.
>
> >
> > 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.
>
>
> I fully understand your point and I agree that a people should be careful
> when naming a class as much as naming his or her daughter.
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
--
Ersin
Re: [ADS 2.0] Naming convention ... again !
Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:
> Hi Emmanuel,
>
> On 9/4/06, *Emmanuel Lecharny* <elecharny@gmail.com
> <ma...@gmail.com>> wrote:
...
> Q4 : if Q1 and Q2 is *NO !!!*, then which name should we use for
> class which implements interface : ConcreteBindRequest,
> BindRequestImpl ?
>
>
> My suggestion is DefaultBindRequest.
>
+1 this is much better than Concrete.
Alex
Re: [ADS 2.0] Naming convention ... again !
Posted by Trustin Lee <tr...@gmail.com>.
Hi Emmanuel,
On 9/4/06, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Hi band,
>
> 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.
>
I agree. Providing BindRequest as an interface is a better approach.
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.
>
I hate adding 'Impl' in the end of a class name. It makes me feel bad
because:
1) I am abbreviating 'implementation'
2) It gives me an impression that it's the only implementation.
So I'd rather suggest DefaultBindRequest or SimpleBindRequest. I prefer
Default because Simple is a little bit vague.
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) ?
>
-1
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)
>
-1
Q3 : Should we add 'Abstract' in front of abstract class ?
>
It's not mandatory when the abstract class contains some meaningful
implementation, and then it can have a different prefix. So... it depends
on context, but adding Abstract is a safe option in most cases.
Q4 : if Q1 and Q2 is *NO !!!*, then which name should we use for class which
> implements interface : ConcreteBindRequest, BindRequestImpl ?
>
My suggestion is DefaultBindRequest.
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.
>
I fully understand your point and I agree that a people should be careful
when naming a class as much as naming his or her daughter.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [ADS 2.0] Naming convention ... again !
Posted by Emmanuel Lecharny <el...@gmail.com>.
>>
>> 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.
>
>
> heh ok I'm not helping :)
Well, I have been a little bit to far :) Let's add Abstract in front of
*all* abstract class, it seems a reasonnable approahc.
I like to keep BindRequest as an concrete class, because this is what
users want to manipulate. Call it common sense... But then we need an
interface to solve the previous problem. I propose BindRequestOperation,
which name does not suggest that it is a concrete class. (and it's
coherent with the Ldap grammar, where requests and response are seen as
Protocol Operations)
>
>> 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) ?
>
>
> Hmmm I've never like this style. -1.
I have used it, but IList sounds strange and IMap looks like the mail
protocol to me :) So let's avoid M$ C# and Hungarian notations to close
source :)
>
>> 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)
>
>
> Yeah -1 on that.
ok, definitively a -1, I think.
>
>> Q3 : Should we add 'Abstract' in front of abstract class ?
>
>
> +1
Ok, me too.
>
>> Q4 : if Q1 and Q2 is *NO !!!*, then which name should we use for
>> class which implements interface : ConcreteBindRequest,
>> BindRequestImpl ?
>
>
> Either is fine w/ me as long as we're consistent. Concrete prefix is
> not bad. I kind of like the fact that it's what the GoF did in their
> examples.
I think that classes which are not seen from an API could use Concrete
in front of their interface name. However, I'm a little bit reluctant to
use that notation for end users classes... As I said before, the API
users want yo manupulate a BindRequest, not a concreteBindRequest, no ?
>
> Alex
>
Re: [ADS 2.0] Naming convention ... again !
Posted by Ole Ersoy <ol...@yahoo.com>.
+1 on I prefixed to interface names...
Eclipse API's do this a lot, therefore it's cool.
That's the crux of my whole argument.
OH - Got one more! I is shorter than, Impl, hence I
wins. OK OK OK - I'll Shatt up.
--- Alex Karasulu <ao...@bellsouth.net> wrote:
> Emmanuel Lecharny wrote:
> > 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
>
> These sound fine to me.
>
> > and of course an abstract class called
> BindRequestDecorator
>
> The abstract class is easy:
> AbstractBindRequestDecorator ?
>
> > 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.
>
> heh ok I'm not helping :)
>
> > 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) ?
>
> Hmmm I've never like this style. -1.
>
> > 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)
>
> Yeah -1 on that.
>
> > Q3 : Should we add 'Abstract' in front of abstract
> class ?
>
> +1
>
> > Q4 : if Q1 and Q2 is *NO !!!*, then which name
> should we use for class
> > which implements interface : ConcreteBindRequest,
> BindRequestImpl ?
>
> Either is fine w/ me as long as we're consistent.
> Concrete prefix is
> not bad. I kind of like the fact that it's what the
> GoF did in their
> examples.
>
> Alex
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: [ADS 2.0] Naming convention ... again !
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
> 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
These sound fine to me.
> and of course an abstract class called BindRequestDecorator
The abstract class is easy: AbstractBindRequestDecorator ?
> 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.
heh ok I'm not helping :)
> 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) ?
Hmmm I've never like this style. -1.
> 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)
Yeah -1 on that.
> Q3 : Should we add 'Abstract' in front of abstract class ?
+1
> Q4 : if Q1 and Q2 is *NO !!!*, then which name should we use for class
> which implements interface : ConcreteBindRequest, BindRequestImpl ?
Either is fine w/ me as long as we're consistent. Concrete prefix is
not bad. I kind of like the fact that it's what the GoF did in their
examples.
Alex