On 25/01/10 13:48, Emmanuel Lcharny wrote:
Matthew Swift a écrit :
On 25/01/10 13:22, Matthew Swift wrote:
[...]
For cases where client apps want to use a control for which there is
no existing sub-class implementation we provided them the option of
using the "GenericControl" class instead of being forced to
implement a sub-class. The GenericControl class is pretty
straightforward - it implements Control and provides three
constructors:
GenericControl(String oid) // non-critical, null value
GenericControl(String oid, boolean isCritical) // null value
GenericControl(String oid, boolean isCritical, ByteString bytes)
I find the GenericControl name a bit non-obvious.
Cool - we're on the same page here. I see that you have described a
ControlImpl sub class for exactly this purpose in your WIKI page...
I'm not sure I'm a big fan of the ControlImpl name to be honest,
since XXXImpl naming is usually associated with internal
implementation classes which are not usually exposed to client apps
(e.g. PlainSocketImpl in J2SE).
We have had many discussions about how best name a class which is not
abstract. At the end, we decided to follow this rule :
- Interfaces' name is the one we want to identify as the object (in
this case, Control)
- Abstract class are named AbstractXXX. I think it's acceptable
- Implementations' name proposal were : BaseXXX, XXXImpl, or using a
IXXX for the interface and XXX for the class. Per rule #1, we rejected
the third proposal, and we decided that XXXImpl was probably better.
Fair enough - consistency is the main priority and it sounds like you
already have a consistent naming scheme defined.
:-)
Matt
