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 not com.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 version 10.X
, com.yourname.myprotocol12
for version 12.X
) or decide to write even the minor version (com.yourname.myprotocol10
for version 1.0
, com.yourname.myprotocol12
for version 1.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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With