I'm hitting a problem with a helper class I am working on to translate between 2 classes of the same name. Both classes are outside my scope of control, so I can't simply rename them.
My basic options all involve declaring the namespace in full for at least one of the types:
import com.myco.second.long.package.namespace.MyObject;
public class MyObjectConvertor {
MyObject transform(com.myco.first.long.package.namespace.MyObject o) {}
}
Or the reverse approach:
import com.myco.first.long.package.namespace.MyObject;
public class MyObjectConvertor {
com.myco.second.long.package.namespace.MyObject transform(MyObject o) {}
}
Or declaring both namespaces, for a more explicit pattern:
public class MyObjectConvertor {
com.myco.second.long.package.namespace.MyObject
transform(com.myco.first.long.package.namespace.MyObject o) {}
}
Is there another solution that might tidy up these method signatures? I'm wondering if some kind of C++ "typedef" style solution might be possible?
You don't have to get too "creative" about the naming, but if you wrote the code you probably have a fairly good idea of what it does and doesn't do. Finally, remember that the bare class name isn't all that you and the readers of your code have to go on - there are usually namespaces in play as well.
One problem with this style of naming is that the good names are used up before you get to naming classes. An interface called File needs an implementation class called something like ActualFile, ConcreteFile, or (yuck!)
If a class is hard to name or explain then it's probably not following the advice in the previous bullet point. A class name should instantly communicate what the class is. Good names drive good designs. If your problem is what to name exposed internal classes, maybe you should consolidate them into a larger class.
As with other naming guidelines, the goal when naming namespaces is creating sufficient clarity for the programmer using the framework to immediately know what the content of the namespace is likely to be. The following template specifies the general rule for naming namespaces: <Company>. (<Product>|<Technology>) [.<Feature>] [.<Subnamespace>]
There's no way to tidy up the signatures, at least one class will have to be referenced by the fully qualified classname.
And in your special case, I'd even say: don't import any of those classes, use version 3 in your source code so everyone is fully aware, that your transforming classes with the same name that are defined in different packages.
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