The indicated method would be very odd as part of a public API. Whether or not it is crazy as a private or protected part of a class would depend upon how it was being used. The method appears to encapsulate two different quirky aspects, either of which could plausibly be justifiable in some contexts but not others; while it would seem unlikely that both would be justifiable, there's no particular reason why they couldn't be.
The first quirky aspect is the fact that the method is searching for particular fixed strings within the maps. Such behavior is generally ugly (and it would probably be better if the strings were defined as constants) but could be justifiable if:
- The map is never exposed to code outside the package.
- It is necessary to use some collection type to store aggregates, each of which consists of a mapping plus a few other bits of information).
- The use of the encapsulated mapping is such that no key could possibly conflict with the strings that are used for the "few other bits of information".
- The mapping is used so much more than the other bits of information stored within the advocate that using a class which contained a
Map along with the other bits of information would be much more cumbersome than using a map which has a few bits of information associated with magic keys.
Some languages and frameworks would provide alternate means of attaching supplemental information to a type, but the approach indicated here is sometimes the most practical one given Java's type system.
The second ugly aspect is that the code is comparing two objects'
ToString values as a means of comparing the objects. In most cases, either the objects will be strings (in which case one could just compare them), or they would be some other type which has some attribute of type
String such a name, in which case one should cast the objects to that other type, call
GetName on both instances, and compare the resulting strings. If, however, the majority of table entries would only need to store strings, but a few might need to have an entry which combines a string with a small amount of supplemental information, it may in some cases be easier to store things in the table as type
Object with the expectation that every entry will either be a
String, or be some known kind of object. Since Java's type system has no concept of "thing which will either be type1 or type2", using
Object, though ugly, may be the only practical alternative in cases where one of the types is something like
String which would share no common ancestor--other than
Object--with any user class.