You use it when you want to guarantee that you are getting sorted data in a parameter, or when you want to assure the consumer of your method that you are providing sorted data.
If you need your data to be sorted, ask for it to be sorted by asking for the interface that matches what you need. It is likely less expensive for the method sending you the data to give it to you sorted (they get it from a database and can trivially order it, but instead tossed it in a
HashMap because thats what everyone uses) than it is for you to take the
Map and then add it to a
If you need it to be sorted, ask for it to be sorted.
This one is a bit more controversial... there are differing schools of thought here.
If you are producing sorted data by the nature of your method and don't have a reason not to, return back the interface that lets the consumers of your data work with it in the most ways without giving them a concrete implementation (that locks you down).
That 'that locks you down' is part of the controversial bit. Some people will argue that you should return the least constraining (most general) interface when possible (
Map rather than
Collection rather than
I'd go with return the most useful thing for the consumers.
I will put the caveat here that if this is something that will always be sorted, its one thing... if someone might want to subclass it later and not have it be sorted... thats another story. So you need to consider this as part of designing for extension. If it isn't going to be extended ever you get one answer from this deliberation... if it may be extended, there's another possible answer.
why is this bit above a mess and people say things about it in code review?
Well, Liskov substitution principle points out that this would make it harder to subclass later. Method parameters cannot be strengthened by a subtype and return values cannot be relaxed.
By returning a
SortedMap one cannot make a later subclass of the class return a weaker type. Furthermore, if you decide to return a weaker type later for some reason it makes it a major refactoring (changing all of the SortedMaps out there to Maps and possibly changing the calls that make use of that interface into code that has to deal with the weaker type).
It really doesn't matter what you are doing inside your own code. Use a sorted map whenever you've got sorted data and want it in a sorted order. Especially if you are doing
put calls on it at various times and want it to remain in sorted order.
Now, you might be tempted to use a
LinkedHashMap instead if you get all the sorted data in one go, insert it in sorted order, and then only do
remove calls against it if you do any modifications. It's not wrong, and it has some advantages (O(1) lookups rather than O(log n) lookups). But, its rather inflexible only providing the
put and none of the other fun method calls that
SortedMap can give you.
SortedMap doesn't give you that much more over
Map. But there is something else...
SortedMap has been replaced by
NavigableMap since Java 1.6 (the two standard classes that implement
SortedMap also implement
NavigableMap). NavigableMap has all sorts of fun method calls that are often quite useful.