HashMap Objects

What is the difference between :

Map obj = new HashMap();

And

HashMap obj = new HashMap();

Also, I need to know the right situations to use these.

Thanks.

Mark Butcher wrote:What is the difference between :
Map obj = new HashMap();
And
HashMap obj = new HashMap();

Flexibility. If later on you decide that 'obj' should be a TreeMap, the only thing you have to change is that assignment statement. With the second variant you will also have to change every place that 'obj' is referred to specifically as a HashMap.

Also, I need to know the right situations to use these.

Almost invariably #1. I can't honestly think of a situation in which I'd use #2, but one of my cleverer colleagues might.

Winston

[Edit] BTW, Tip: Get used to declaring the element type for your maps and collections. If this map is going to contain Strings, then it should be:
Map<String> obj = new HashMap<String>();

Well, I understood it partially, but an example of this should make it better.

Thanks.

the difference lies on clone method . but if you want such a one you can always cast to HashMap . so prefer Map map = new HashMap().

Mark Butcher wrote:Well, I understood it partially, but an example of this should make it better.

I don't follow. What kind of "example" are you thinking of?

You have two styles of declaration, and I've just told you that the first is more flexible. Programs change, that's their nature; so anything you can do to minimize that change, when (or if) you need to do it, is generally a good thing (quite apart from the fact that the first is less to type; always a consideration for me and my CTS.

).

For a better explanation of why you might want to do it, start here.

Winston

Winston Gutkowski wrote:

Also, I need to know the right situations to use these.

Almost invariably #1. I can't honestly think of a situation in which I'd use #2, but one of my cleverer colleagues might.

I wouldn't claim to be a cleverer colleague

, but you'd do it if you needed to use some feature of HashMap that wasn't part of the Map interface. In this case, it appears the only thing is that HashMap has a public clone() method, so there's not much call for that. But with some other parts of the collection framework you do get some specialised methods in the class that don't appear in the interface (e.g. the capacity related methods in ArrayList that don't appear in List).

Winston Gutkowski wrote:
[Edit] BTW, Tip: Get used to declaring the element type for your maps and collections. If this map is going to contain Strings, then it should be:
Map<String> obj = new HashMap<String>();

Of course, you meant Map<String, String> obj = new HashMap<String, String>();

Seetharaman Venkatasamy wrote:the difference lies on clone method...

???

Winston

[Edit] Oh OK. Matthew's post just explained what you mean. Seems a pretty thin reason for using #2 over #1 though.

Matthew Brown wrote:Of course, you meant Map<String, String> obj = new HashMap<String, String>();

Doh-h-h!! Of course I did. Thanks.

Winston

Winston Gutkowski wrote:Seems a pretty thin reason for using #2 over #1 though.

I'd agree. If you really want a copy you could just use a copy constructor. So instead of:
You'd use:

Winston Gutkowski wrote: . . . Seems a pretty thin reason . . .

I always worry about methods which appear mysteriously in sub‑classes. Why have ArrayList and Vector got an ensureCapacity() method which isn’t in the List interface? Why isn’t there a Resizeable interface for that method? Wouldn’t that reduce the messing about with instanceof?

Campbell Ritchie wrote:I always worry about methods which appear mysteriously in sub‑classes. Why have ArrayList and Vector got an ensureCapacity() method which isn’t in the List interface? Why isn’t there a Resizeable interface for that method? Wouldn’t that reduce the messing about with instanceof?

Hmmm. Tricky one that. That means that you'd have an ensureCapacity() method for a LinkedList, which seems kind of pointless. Seems to me that they could have made a major division between RandomAccess Lists and Sequential ones, but maybe they didn't want to blind people with too many interfaces.

I like the Resizeable idea though.

Winston

No, you don’t need ensureCapacity() in a LinkedList. You could always implement it empty, but that’s pretty daft. I meant that ensureCapacity would be in the Resizeable interface. Rather than having to go through. . . you would only need once test and cast to Resizeable.

RandomAccess probably doesn’t quite fit the bill.

Campbell Ritchie wrote:you would only need once test and cast to Resizeable.
RandomAccess probably doesn’t quite fit the bill.

I think, then we will end up with more,more..interfaces

Seetharaman Venkatasamy wrote:I think, then we will end up with more,more..interfaces

Personally, I don't have any particular problem with that, providing it's within reason. In fact, it suggests to me that there is possibly a case to be made for a division into "linked" and "contiguous" lists (although what to call them, I have no idea), with Campbell's 'Resizeable' being part of the latter.

I have to admit to not particularly liking "add ons" like RandomAccess because they're too easy to forget - although exactly what the alternative is I don't know - and strangely enough, I've often thought that an 'Immutable' marker might not be a bad thing either.

Ah design - don't you love it?

Winston

The way I see it, the whole concept of capacity is an implementation detail, so I'm not convinced I'd like it in an interface*. But it's an implementation detail that you do want to be able to tweak on occasion for efficiency, which is the only reason to expose it at all.

* I suppose it wouldn't hurt, though. But not called Resizable - enough beginners get confused about the difference between size and capacity as it is!

The other thing is...my imagination is struggling here a bit, but it's entirely possible that if you tried to define lots of different ways of implementing lists, they wouldn't split nicely into "those that have a capacity" and "those that don't". Different implementations may have different tweakable implementation details. For example, in Scala a Vector (no relation to a Java Vector) is implemented by a tree of smaller lists. Maybe the size of those small lists would be something you might want to expose in the concrete type (though in that particular example I don't think it does).

Matthew Brown wrote:...but it's entirely possible that if you tried to define lots of different ways of implementing lists, they wouldn't split nicely into "those that have a capacity" and "those that don't"...

I quite agree, and I have to admit to not having thought it through completely, but whether a List is "linked" or not seems to me to be a fairly fundamental statement of what it's likely to be "good at" and what it isn't. Personally, I think the List interface is a bit overblown anyway (not its fault, admittedly). I always worry when I see lots of "optional" methods.

Winston

Winston Gutkowski wrote:
Ah design - don't you love it?

And then you can see that different people have different opinions, and you need to work out whether those opinions converge or diverge as they are discussed.