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 :
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.