Java naming convention for a class with version in its name?

Question

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?

Leandro

I'm voting to close this question as off-topic because it is asking for best practices in certain technology or program – Diffractive

I this was covered in the Google Java Style Guide? – Muss

You should not put the version number in the class name. You should rather put them in a package name likecom.company.protocol.11_0.MyHandler. and of cause there should by an interface without version com.company.protocol.MyHandler – Hiltan

@Diffractive The MYP protocol is fictitious, it could be any protocol. – Leandro

@TimothyTruckle It is ok to have a underscore in package name? The Google Java Style Guide, for example, is against it when naming packages. – Leandro

@AndrewTobilko I understand you point of view, but what if there are significant interface differences between two versions and it is intended to have a class for both versions in parallel. – Leandro

@Leandro not using underscores is a convention to support readability within the Language. You will not be arrested if you break it, but you should have a reason. In the case of package names the reason is that the alternatives to separating the version parts by underscores are less desirable: dots increase the folder dept and make the version parts less connected then the rest of the package names, the dash (minus) is not allowed and the dollar sign is just ugly... – Hiltan

Answer 1

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.

Margarettamargarette

Your solution seems very reasonable. But I must ask, when deciding the precision I use to write the version, how to avoid conflicts like com.yourname.myprotocol120, which is not obvious wether it refers to version 1.20.X or 12.0.X? – Leandro

@Leandro I don't think there is way to specify it without using fancy stuff like com.yourname.myprotocol1_20 for version 1.20 and com.yourname.myprotocol12_0 for version 12.0. Consider using dots: com.yourname.myprotocol.1.20 for version 1.20 and com.yourname.myprotocol.12.0 for version 12.0. To make it less ambiguos you can use @version in the javadoc :) – Margarettamargarette

@Someone com.yourname.myprotocol.1.20 is an invalid package name. – Southward

We currently use the "image bitmap notation", where we specify versions 1.2.0 in method names as myMethod1x2x0() and 12.0 as myMethod12x0x0() or myMethod12x0() respectively in the method names. We had to use this notation in our codebase, because the underscore has a different legacy meaning associated in our method names. – Stibine