Suppose I have different classes to deal with different versions of the same protocol (with possibly different interfaces). For example, a fictitious protocol named My Protocol (MYP):
My Protocol (MYP) versions 1.0, 1.1, 2.0, 2.2, etc...
Some naming examples I could think of are:
MYP10Handler
, MYP11Handler
, MYP20Handler
, MYP22Handler
, ...
MYP1_0Handler
, MYP1_1Handler
, MYP2_0Handler
, MYP2_2Handler
, ...
If using the first option, for example, there would be ambiguities if the protocol reaches higher versions. For example, version 11.0 (eleven):
MYP11Handler
: Version 1.1 or 11.0?
MYP110Handler
: Version 11.0 or 1.10?
The second option, however, seems to escape the Camel Case rule.
How naming is usually done to these types of class? Is there a better practice for this?
You should all the files/classes relative to a certain version of the entire program's part in a package with a name representing that specific version.
When you want to add a new version of your protocol, you should create a new package, copy all the old files, and start with the new stuff, and all the files/classes should have the same name in every package (
com.yourname.myprotocol14.MyProtocolHandler
, of course notcom.yourname.myprotocol14.MyProtocolHandler14
)You must decide with what precision you write the version on the package name: you could just put the major version (
com.yourname.myprotocol10
for version10.X
,com.yourname.myprotocol12
for version12.X
) or decide to write even the minor version (com.yourname.myprotocol10
for version1.0
,com.yourname.myprotocol12
for version1.2
), it's up to you.The user can decide what version of the library (assume it is a library) he wants to use by just importing
com.yourname.myprotocol[version number]
, and for this reason you should put all the files relative to the library inside every package.