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
