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 <[EMAIL PROTECTED]> wrote:
Hi Emmanuel, On 9/4/06, Emmanuel Lecharny <[EMAIL PROTECTED]> 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
