小编典典
对象之间没有区别;HashMap在两种情况下,你都有一个。你与对象之间的接口有所不同。在第一种情况下,接口为HashMap,而在第二种情况下为Map。但是底层对象是相同的。
使用Map它的好处是你可以将基础对象更改为另一种类型的映射,而不会与使用它的任何代码破坏合同。如果将其声明为HashMap,则要更改基础实现,则必须更改合同。
示例:假设我编写了此类:
class Foo {
private HashMap things;
private HashMap moreThings;
protected HashMap getThings() {
return this.things;
}
protected HashMap getMoreThings() {
return this.moreThings;
}
public Foo() {
this.things = new HashMap();
this.moreThings = new HashMap();
}
// ...more...
}
该类有一些string-> object的内部映射,它与子类共享(通过访问器方法)。假设我以HashMaps开头,因为我认为这是编写类时要使用的适当结构。
后来,玛丽编写了将其子类化的代码。她与thingsand都需要做一些事情moreThings,因此自然而然地将它放在一个通用方法中,并且在定义她的方法时使用与getThings/ 上使用的类型相同的类型getMoreThings:
class SpecialFoo extends Foo {
private void doSomething(HashMap t) {
// ...
}
public void whatever() {
this.doSomething(this.getThings());
this.doSomething(this.getMoreThings());
}
// ...more...
}
后来,我决定实际上,最好使用TreeMap而不是HashMapin Foo。我更新Foo,更改HashMap为TreeMap。现在,SpecialFoo不再编译了,因为我违反了合同:Foo曾经说它提供了HashMaps,但是现在提供了TreeMaps。因此,我们必须立即修复SpecialFoo(这种情况可能会在代码库中引起涟漪)。
除非我有一个很好的理由要分享我的实现正在使用HashMap(并且确实发生了),否则我应该做的就是声明,getThings然后getMoreThings返回Map而没有任何更具体的说明。实际上,除非有充分的理由做其他事情,甚至在Foo我可能应该将things和声明moreThings为as Map,而不是HashMap/ TreeMap:
class Foo {
private Map things; // <== Changed
private Map moreThings; // <== Changed
protected Map getThings() { // <== Changed
return this.things;
}
protected Map getMoreThings() { // <== Changed
return this.moreThings;
}
public Foo() {
this.things = new HashMap();
this.moreThings = new HashMap();
}
// ...more...
}
请注意,我现在正在如何尽可能地使用Map它,仅在创建实际对象时才具体说明。
如果我这样做了,那么玛丽就会做到这一点:
class SpecialFoo extends Foo {
private void doSomething(Map t) { // <== Changed
// ...
}
public void whatever() {
this.doSomething(this.getThings());
this.doSomething(this.getMoreThings());
}
}
…而且更改Foo不会使SpecialFoo编译停止。
接口(和基类)使我们仅显示必要的内容,因此可以灵活地进行更改。总的来说,我们希望参考文献尽可能基本。如果我们不需要知道它是a HashMap,则称它为a Map。
这不是盲目的规则,但总的来说,与最特定的接口编码相比,对最通用的接口进行编码将不那么困难。如果我还记得这一点,那我就不会创建一个Foo将Mary设置为失败的SpecialFoo。如果Mary记得这一点,那么即使我搞砸了Foo,她也会用Map而不是声明自己的私有方法,而HashMap我更改Foo的合同不会影响她的代码。
有时候你做不到,有时候你必须要具体。但是除非有理由,否则请偏向最不具体的界面。
2020-03-05