HashMap m = new HashMap(); --(1)
Map m = new HashMap(); -- (2)
Please advise. Thanks!
In the second example, the HashMap can be replaced with some other kind
of Map without any of the rest of the code needing to be examined. This
could come in handy if we decide to try out different types of Maps to
see which gives better performance (for example.)
(2) is usually better than (1) because it is more general.
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
The "point" being that if (2) is of "base" class static type then it
should be able to point to ALL member classes of the type class
family (hierarchy/tree/taxonomy :- ).
> "Distinguishing between the author
> and the writing is the essence of civilized debate."
> -- Daniel Parker
I'd still appreciate a lucid explique of this remark. DP perhaps?
In what way is an author not responsible for her writing? Not
responsible for what it conveys? Not responsible for defending
what she objectively promotes, advocates, opposes in her writing?
Elliott
--
This behavior of overlooking or deprecating the system approach and
scientific method in some cases, is at best, pathetically, poor
academics, and sloppy engineering. And in a number of other cases
where dollars matters most, it's dishonest opportunism and an
abrogation of intellectual integrity.
It depends on the context where m has to be used. If the context requires
HashMap, i.e. when the code is specific to HashMap, then (1) is the choice.
If the code is class-wide, i.e. valid for any Map, then (2) is better, but
it would also indicate a potential design problem. If the code is valid for
any Map then why HashMap is chosen? Perhaps one can rewrite it in terms of
Map?
Map m = MapFactory.Create (some reasonable parameters);
or
Map m = Copy (OtherMap);
...
--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de
And better yet:
m := HashMap new.
because it is the most general.
:-)
Nevin Pratt
ne...@smalltalkpro.com
DP
> I think this is more on OO design question? In the following code,
>
> HashMap m = new HashMap(); --(1)
> Map m = new HashMap(); -- (2)
>
> I [know that] the best practice is (1),
> but I still don't understand why.
> So the rule of thumb is if possible,
> it is best to create an instance of a class
> that pointed to by interface of that class?
In C++, you would write:
HashMap m;
Sometimes you would write:
Map* m = new HashMap();
One could argue the latter was better in many cases.
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
> E. Robert Tisdale wrote:
>
>>Matt wrote:
>>
>>>I think this is more on OO design question? In the following code,
>>>
>>> HashMap m = new HashMap(); --(1)
>>> Map m = new HashMap(); -- (2)
>>>
>>>I [know that] the best practice is (1),
>>>but I still don't understand why.
>>>So the rule of thumb is if possible,
>>>it is best to create an instance of a class
>>>that pointed to by interface of that class?
>>
>>In C++, you would write:
>>
>> HashMap m;
>
> Sometimes you would write:
>
> Map* m = new HashMap();
>
> One could argue the latter was better in many cases.
I don't think so
but I'm willing to entertain one's argument to the contrary.
Are you that one?
My golden rule is to declare a variable, method parameter, etc. as
abstractly as I can as long as I don't have to downcast. So in this
example, I would go with Map. Why? Let's suppose you pass this Map
around to a few methods. Following the golden rule, the methods take
in Map. If the methods take in HashMap, and you later realize that
you need the Map sorted, you've got to change all those references
from HashMap to SortedMap; that's every method and the new call.
Following the golden rule, you only change the new.
I found the excerpted post of yours to be quite profound. I'd take it as a
complement. Although distinguishing between civilized debate and Usenet is
also essential, IMHO. =)
--
.:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.
: please talk to your son or daughter about parametric polymorphism. :
One of us is missing something here.
I think that the implication was that HashMap is derived from Map.
Can I infer that your SortedMap is also derived from Map?
If so, you would simple write
SortedMap m;
in C++ and pass m to any function on a Map object.
Right
> Can I infer that your SortedMap is also derived from Map?
Yes.
> If so, you would simple write
>
> SortedMap m;
>
> in C++ and pass m to any function on a Map object.
You could do that, but I would declare m as Map:
Map m;
Again, as long as I don't have to downcast, I would do this. The
reason is to minimize the places where I have to change code when/if I
realize I need a different kind of Map. So looking at the two
options. I really have a HashMap, but realize I need a SortedMap:
HashMap m; // change here
...
m = new HashMap(); // change here
Map m;
...
m = new HashMap(); // change here
-----------
Clint Shank
> > "Universe" <univ...@covad.net> wrote in message
news:<2abf0$40725c43$97cff003
> >> "Robert C. Martin" <uncl...@objectmentor.com> wrote in message
> >>
> >> > "Distinguishing between the author
> >> > and the writing is the essence of civilized debate."
> >> > -- Daniel Parker
> >> I'd still appreciate a lucid explique of this remark. DP perhaps?
> >>
> >> In what way is an author not responsible for her writing? Not
> >> responsible for what it conveys? Not responsible for defending
> >> what she objectively promotes, advocates, opposes in her writing?
> > Actually, I've been a little annoyed at RCM for putting this in his
> > sig. Ever since, I've felt somewhat obligated to live up to it, which
> > has caused me to remove entire sentences from my posts, and edit out
> > digs at one of my favourite targets. It's unclear what benefits RCM
> > expected to result from quoting this.
I'm still interested in what you meant.
> I found the excerpted post of yours to be quite profound. I'd take it as a
> complement. Although distinguishing between civilized debate and Usenet is
> also essential, IMHO. =)
Then please "mayhaps" you'll post your understanding of it?
Elliot
--
Substituting Refactoring For Analysis Modelling and Review
When Facing Major High Level Design Problems
Is Like Drawing a Shade When Totally Dark