blocks|key|308441|text|这种做法并不局限于Java。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|308442|当您想要将对象的实例从您正在使用的类中分离出来时，也经常在.NET中使用它。如果您使用的是接口而不是类，则可以在需要时随时更改支持类型，而不会破坏其余代码。|308443|您还将看到大量使用工厂模式处理IoC容器和实例化的实践。|308444|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

This practice isn't just limited to Java. 

It's often used in .NET as well when you want to de-couple the instance of the object from the class you're using. If you use the Interface rather than the Class, you can change the backing type whenever needed without breaking the rest of your code.

You'll also see this practice used heavily with dealing with IoC containers and instanciation using the Factory pattern.

blocks|key|420099|text|据我所知，Java开发人员比.NET开发人员更倾向于使用抽象(和设计模式)。这似乎是另一个例子:当他本质上只使用接口成员时，为什么要声明具体的类？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|420100|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

As far as I've seen Java developers tend to use abstraction (and design patterns) more often than .NET developers. This seems another example of it: why declare the concrete class when he'll essentially only be working with the interface members?

blocks|key|1715092|text|我发现，对于局部变量，使用接口或具体类通常无关紧要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1715093|与类成员或方法签名不同，如果您决定更改类型，则重构工作非常少，变量在其使用位置之外也不可见。实际上，当您使用var声明局部变量时，您得到的不是接口类型，而是类类型(除非您显式强制转换为接口)。|offset|length|style|CODE|1715094|但是，在声明方法、类成员或接口时，我认为预先使用接口类型而不是将公共API耦合到特定的类类型会省去很多麻烦。|1715095|entityMap^0|0|1I|3|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I've found that for local variables it generally doesn't much matter whether you use the interface or the concrete class.

Unlike class members or method signatures, there is very little refactoring effort if you decide to change types, nor is the variable visible outside its usage site. In fact, when you use <code>var</code> to declare locals, you are not getting the interface type but rather the class type (unless you explicitly cast to the interface).

However, when declaring methods, class members, or interfaces, I think that it will save you quite a bit of headache to use the interface type up front, rather than coupling the public API to a specific class type.

blocks|key|308525|text|使用接口意味着以下代码中的“字典”可能是IDictionary的任何实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|308526|Dictionary1+dictionary+=+new+Dictionary1();
dictionary.operation1();+//+if+operation1+is+implemented+only+in+Dictionary1()+this+will+fail+for+every+other+implementation|code-block|syntax|javascript|308527|当您隐藏对象的构造时，效果最好：|308528|IDictionary+dictionary+=+DictionaryFactory.getDictionary(...);|308529|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Using interfaces means that "dictionary" in the following code might be any implementation of IDictionary. 

<pre><code>Dictionary1 dictionary = new Dictionary1();
dictionary.operation1(); // if operation1 is implemented only in Dictionary1() this will fail for every other implementation
</code></pre>

It's best seen when you hide the construction of the object:

<pre><code>IDictionary dictionary = DictionaryFactory.getDictionary(...);
</code></pre>

blocks|key|1715184|text|在上述情况下，几乎每个Java开发人员都会使用该接口来声明变量。Java集合的使用方式可能是最好的例子之一：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1715185|Map+map+=+new+HashMap();
List+list+=+new+ArrayList();|code-block|syntax|javascript|1715186|我猜它只是在很多情况下实现了松散耦合。|1715187|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

In the described situation almost every Java developer would use the interface to declare the variable. The way the Java collections are used is probably one of the best examples:

<pre><code>Map map = new HashMap();
List list = new ArrayList();
</code></pre>

Guess it just accomplishes loose coupling in a lot of situations.

blocks|key|308649|text|我在Java开发人员中遇到过同样的情况。他以相同的方式将集合和对象实例化到它们的接口。例如,|type|unstyled|depth|inlineStyleRanges|entityRanges|data|308650|IAccount+account+=+new+Account();|code-block|syntax|javascript|308651|属性总是以接口的形式获取/设置。这会导致序列化问题，here对此进行了很好的解释|offset|length|308652|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1003715/using-an-interface-in-a-c-xml-web-service^0|0|0|Q|4|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@$I|V|J|W|1|X]]|A|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R]]]]

I've encountered the same situation with a Java developer. He instantiates collections AND objects to their interface in the same way.
For instance, 

<pre><code>IAccount account = new Account();
</code></pre>

Properties are always get/set as interfaces. This causes problems with serialization, which is explained very well <a href="https://stackoverflow.com/questions/1003715/using-an-interface-in-a-c-xml-web-service">here</a>

blocks|key|1715301|text|您应该始终尝试对接口而不是具体的类进行编程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1715302|在Java或任何其它面向对象编程语言中。|1715303|在.NET世界中，使用I来表示您正在使用的接口是很常见的。我认为这更常见，因为在C#中，他们没有implements和extends来引用类与接口继承。|offset|length|style|CODE|1715304|我想乳清会打字|1715305|+class+MyClass:ISome,Other,IMore+
+{+
+}|code-block|syntax|javascript|1715306|你可以告诉ISome+IMore是接口，而Other是一个类|1715307|在Java中，不需要这样的东西|1715308|+class+MyClass+extends+Other+implements+Some,+More+{
+}|1715309|这个概念仍然适用，您应该尝试对接口进行编码。|1715310|entityMap^0|0|0|B|1|1C|A|1N|7|0|0|0|5|5|B|5|L|5|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@$F|13|G|14|H|I]|$F|15|G|16|H|I]|$F|17|G|18|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|19|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1A|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|1B|8|@$F|1C|G|1D|H|I]|$F|1E|G|1F|H|I]|$F|1G|G|1H|H|I]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1I|8|@]|9|@]|A|$]]|$1|U|3|V|5|N|7|1J|8|@]|9|@]|A|$O|P]]|$1|W|3|X|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|Z|$]]

You should always attempt to program to the interface rather than the concrete class.

In Java or any other object oriented programming language. 

In .NET world is common to use an <code>I</code> to indicate that is an interface what your're using. I think this is more common because in C# they don't have <code>implements</code> and <code>extends</code> to refer class vs interface inheritance. 

I think whey would type

<pre><code> class MyClass:ISome,Other,IMore 
 { 
 }
</code></pre>

And you can tell <code>ISome</code> an <code>IMore</code> are interfaces while <code>Other</code> is a class

In Java there is no need for such a thing

<pre><code> class MyClass extends Other implements Some, More {
 }
</code></pre>

The concept still applies, you should try to code to the interface.

blocks|key|1721123|text|如果IDictionary是一种比字典“更通用”的类型，那么在声明变量时使用更通用的类型是有意义的。通过这种方式，您不必关心分配给变量的实现类，并且将来可以轻松地更改类型，而不必更改大量以下代码。例如，在Java中，通常认为这样做更好|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1721124|List<Integer>+intList=new+LinkedList<Integer>();|code-block|syntax|javascript|1721125|比它要做的更多|1721126|LinkedList<Integer>+intList=new+LinkedList<Integer>();|1721127|这样，我确信下面的所有代码都将List视为list，而不是LinkedList，这样将来就可以很容易地为Vector类或任何其他实现List的类切换LinkedList。我要说的是，这对于Java和一般的好的编程来说是很常见的。|1721128|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

If IDictionary is a "more generic" type than Dictionary then it makes sense to use the more generic type in declaring variables. That way you don't have to care as much about the implementing class assigned to the variable and you can change the type easily in the future without having to change a lot of following code. For example, in Java it's often considered better to do

<pre><code>List&lt;Integer&gt; intList=new LinkedList&lt;Integer&gt;();
</code></pre>

than it is to do

<pre><code>LinkedList&lt;Integer&gt; intList=new LinkedList&lt;Integer&gt;();
</code></pre>

That way I'm sure all following code treats the list as a List and not a LinkedList, making it easy in the future to switch out LinkedList for Vector or any other class which implements List. I'd say this is common to Java and good programming in general.

blocks|key|420140|text|你的朋友正在遵循一个非常有用的原则：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|420141|“将自己从实现细节中抽象出来”|420142|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Your friend is following the very useful principle:

"Abstract yourself from implementation details"

blocks|key|1721224|text|Java集合包括许多实现。因此，对我来说，更容易使用|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1721225|List<String>+myList+=+new+ArrayList<String>();|code-block|syntax|javascript|1721226|然后在将来，当我意识到我需要"myList“是线程安全的时候，只需将这一行改为|1721227|List<String>+myList+=+new+Vector<String>();|1721228|并且不更改其他代码行。这也包括getters/setters。例如，如果你看一下Map的实现数量，你就可以想象为什么这可能是一个好的实践。在其他语言中，只有几个实现(对不起，不是很大的.NET人员)，但在Objective-C中，实际上只有NSDictionary和NSMutableDictionary。所以，这就没什么意义了。|1721229|编辑：|1721230|未能触及我的一个关键点(只是用getter/setters暗示了一下)。|1721231|以上功能可让您拥有：|1721232|public+void+setMyList(List<String>+myList)+{
++++this.myList+=+myList;
}|1721233|使用此调用的客户端无需担心底层实现。使用符合它们可能具有的List接口的任何对象。|1721234|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|10|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|11|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|D|7|16|8|@]|9|@]|A|$E|F]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

Java Collections include a multitude of implementations. Therefore, it's much easier for me to make use of 

<pre><code>List&lt;String&gt; myList = new ArrayList&lt;String&gt;();
</code></pre>

Then in the future when I realize I need "myList" to be thread safe to simply change this single line to

<pre><code>List&lt;String&gt; myList = new Vector&lt;String&gt;();
</code></pre>

And change no other line of code. This includes getters/setters as well. If you look at the number of implementations of Map for example, you can imagine why this might be good practice. In other languages, where there is only a couple implementations for something (sorry, not a big .NET guy) but in Objective-C there is really only NSDictionary and NSMutableDictionary. So, it doesn't make as much sense.

Edit:

Failed to hit on one of my key points (just alluded to it with the getter/setters). 

The above allows you to have:

<pre><code>public void setMyList(List&lt;String&gt; myList) {
 this.myList = myList;
}
</code></pre>

And the client using this call need not worry about the underlying implementation. Using whatever object that conforms to the List interface that they may have.

blocks|key|308707|text|对于已经是实现细节的局部变量和私有字段，使用具体类型比使用接口声明更好，因为具体类提供了性能提升(直接分派比虚拟/接口分派更快)。如果您不在本地实现细节中不必要地强制转换为接口类型，JIT还将能够更容易地内联方法。如果从返回接口的方法返回具体类型的实例，则强制转换是自动的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|308708|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For local variables and private fields, which are already implementation details, it's better to use concrete types than interfaces for the declarations because the concrete classes offer a performance boost (direct dispatch is faster than virtual/interface dispatch). The JIT will also be able to more easily inline methods if you don't unnecessarily cast to interface types in the local implementation details. If an instance of a concrete type is returned from a method that returns an interface, the cast is automatic.

blocks|key|420264|text|我来自Java世界，我同意“面向接口的编程”这句咒语已经灌输给您了。通过对接口而不是实现进行编程，您可以使您的方法更具可扩展性，以满足未来的需求。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|420265|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Coming from a Java world, I agree that the "program to an interface" mantra is drilled into you. By programming to an interface, not an implementation, you make your methods more extensible to future needs.

blocks|key|1715437|text|IDictionary是一个接口，Dictionary是一个类。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1715438|Dictionary实现了IDictionary。|1715439|这意味着可以使用/通过Dictionary实例引用IDictionary实例，并通过IDictionary实例调用大多数Dictionary方法和属性。|1715440|强烈建议尽可能多地使用接口，因为接口抽象了应用程序的模块和程序集，允许多态性，这在许多情况下都很常见和有用，并且允许在不接触其他模块的情况下用另一个模块替换一个模块。|1715441|假设在现在，程序员写道：|1715442|IDictionary<string>+dictionary+=+new+Dictionary<string>();|1715443|现在，dictionary调用Dictionary<string>的方法和属性。|1715444|在未来，数据库的大小已经增长，我们发现Dictionary<string>太慢了，所以我们想用更快的RedBlackTree<string>来取代Dictionary<string>。|1715445|因此，需要做的就是将上面的指令替换为：|1715446|IDictionary<string>+dictionary+=+new+RedBlackTree<string>();|1715447|当然，如果RedBlackTree实现了IDictionary，那么应用程序的所有代码都会成功编译，您的应用程序就会有一个更新的版本，应用程序现在的执行速度和效率都比以前的版本更快、更有效。|1715448|如果没有接口，这种替换将更加困难，并且需要程序员和开发人员更改更多可能出现bug的代码。|1715449|entityMap^0|0|B|H|A|0|0|A|D|B|0|B|A|P|B|16|B|1O|A|0|0|0|0|1M|0|3|A|F|I|0|J|I|1E|K|21|I|0|0|0|1O|0|5|C|K|B|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@$9|14|A|15|B|C]|$9|16|A|17|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|18|8|@$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1D|8|@$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1M|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1N|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1O|8|@$9|1P|A|1Q|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1R|8|@$9|1S|A|1T|B|C]|$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|1W|8|@$9|1X|A|1Y|B|C]|$9|1Z|A|20|B|C]|$9|21|A|22|B|C]]|D|@]|E|$]]|$1|T|3|U|5|6|7|23|8|@]|D|@]|E|$]]|$1|V|3|W|5|6|7|24|8|@$9|25|A|26|B|C]]|D|@]|E|$]]|$1|X|3|Y|5|6|7|27|8|@$9|28|A|29|B|C]|$9|2A|A|2B|B|C]]|D|@]|E|$]]|$1|Z|3|10|5|6|7|2C|8|@]|D|@]|E|$]]|$1|11|3|-4|5|6|7|2D|8|@]|D|@]|E|$]]]|12|$]]

<code>IDictionary</code> is an interface and <code>Dictionary</code> is a class.

<code>Dictionary</code> implements <code>IDictionary</code>.

That means that this is possible to refer to <code>Dictionary</code> instance with/by <code>IDictionary</code> instance and invoke most of the <code>Dictionary</code> methods and properties through <code>IDictionary</code> instance.

This is very recommended to use interfaces as many as possible, because interfaces abstracts the modules and assemblies of the applications, allows polymorphism, which is both very common and useful in many situations and cases and allows replacing one module by another without touching the other modules.

Suppose that in the present, the programmer wrote:

<code>IDictionary&lt;string&gt; dictionary = new Dictionary&lt;string&gt;();</code>

And now <code>dictionary</code> invokes the methods and properties of <code>Dictionary&lt;string&gt;</code>.

In the future the databases has been grown up in size and we find out that <code>Dictionary&lt;string&gt;</code> is too slow, so we want to replace <code>Dictionary&lt;string&gt;</code> by <code>RedBlackTree&lt;string&gt;</code>, which is faster.

So all what is needed to be done is replacing the above instruction to:

<code>IDictionary&lt;string&gt; dictionary = new RedBlackTree&lt;string&gt;();</code>

Of course that if <code>RedBlackTree</code> implements <code>IDictionary</code> then all the code of the application compiles successfully and you have a newer version of your application, where the application now performs faster and more efficient than the previous version.

Without interfaces, this replacement would be more difficult to do and would require the programmers and developers to change more code that is potential to bugs.

I have a friend who's just getting into .NET development after developing in Java for ages and, after looking at some of his code I notice that he's doing the following quite often:

<pre><code>IDictionary&lt;string, MyClass&gt; dictionary = new Dictionary&lt;string, MyClass&gt;();
</code></pre>

He's declaring dictionary as the Interface rather than the Class. Typically I would do the following:

<pre><code>Dictionary&lt;string, MyClass&gt; dictionary = new Dictionary&lt;string, MyClass&gt;();
</code></pre>

I'd only use the IDictionary interface when it's needed (say, for example to pass the dictionary to a method that accepts an IDictionary interface).

My question is: are there any merits to his way of doing things? Is this a common practice in Java?

A difference in style: IDictionary vs Dictionary

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一个朋友，在用Java语言开发了很长时间之后，他刚刚进入.NET开发领域，在看了他的一些代码后，我注意到他经常做以下事情：IDictionary<string, MyClass> dictionary = new Dictionary<string, MyClass>();他将字典声明为接口，而不是类。通常，我会执...

问风格上的差异: IDictionary与字典
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问风格上的差异: IDictionary与字典EN