[Translation] Why does list implement so many interfaces?

Address: http://blogs.msdn.com/ B /ericlippert/archive/2011/04/04/so-many-interfaces.aspx

Original Author: Eric lippert

Eric lippert is a Microsoft employee and one of the major developers of C # compilers.

Today, I answered a question on stackoverflow. According to my previous habits, I organized it into a blog in the form of dialogs.

In the msdn document, list <t> is declared as follows:

 
Public ClassList: ilist <t>, icollection <t>, ienumerable <t>, ilist, icollection, ienumerable
 

So does list actually implement so many interfaces?

Yes.

Why are there so many interfaces?

For example, if ilist <t> is derived from ienumerable <t>, the implementer of an interface with a higher degree of derivation must implement an interface with a lower degree of derivation. Interface inheritance is like this; if you want to meet the contract of a type with a higher degree of derivation, you must satisfy the type with a lower degree of derivation.

So a class or a struct must implement all the methods defined by all interfaces on its passing closure?

Very correct.

A class or struct that implements an interface with a higher degree of derivation must declare in its base type list that it implements interfaces with lower degree of derivation?

No.

Will the statement be banned?

No.

So is the interface with a low degree of derivation declared as optional in the base class list?

Yes.

Is this always the case?

Basically, this is always the case:

 
InterfaceI1 {}InterfaceI2: I1 {}InterfaceI3: I2 {}
 

Whether I3 explicitly indicates that I1 is optional.

 
ClassB: I3 {}
 

The implementers of I3 must implement I2 and I1, but they do not have to be explicitly specified. Indicates whether it is optional.

 
ClassD: B {}
 

The derived class indicates that it implements the interface of its base class, but this is not necessary.

The following is an example:

 
ClassC <t>WhereT: I3 {Public Virtual VoidM <u> ()WhereU: I3 {}}
 

 

The type parameters corresponding to T and U must implement I2 and I1, but the generic type constraints of t u do not have to be explicitly specified.

Whether to re-declare the interfaces implemented by the distribution class is also Optional:

Partial ClassE: I3 {}Partial ClassE {}
 

The second part of Type E can declare that it implements I3, I2, or I1, but not necessarily.

Okay, I understand. This is optional. How can someone declare an interface that is not necessarily declared?

Probably because they think this will makeCodeIt is easier to read and more self-explanatory.

A developer may write the following code:

 
InterfaceI1 {}InterfaceI2 {}InterfaceI3: I1, I2 {}
 

Then he suddenly realized that I2 should inherit from i1.Why do developers need to modify I2 to inherit from I1 and then delete the i1 inheritance in the I3 statement?I cannot find any reason to force the developer to delete redundant declaration information.

Besides being easy to understand and easy to understand, you can explicitly declare an interface in the base class list and implement this interface even though it is not declared.Technically?

Usually none, but there is a slight difference. Suppose there is a type D, and its base class B implements some interfaces. D. Those interfaces are automatically implemented through B. If you explicitly declare these interfaces in the base class list of D, the C # compiler will doInterface implementation. The details are a bit obscure. If you are interested in this, I suggest you carefully read section 13.4.6 of the C #4 Language Specification. Basically, the compiler will "Start again" and find out which method implements which interface.

List <t>Source codeAre so many interfaces explicitly declared in?

No. The real source code is as follows:

 
Public ClassList <t>: ilist <t>, system. Collections. ilist
 

Although the Source Code does not explicitly declare all interfaces, why does msdn still list all interfaces?

Because msdn is a document, it should provide as much information as possible. It is better to provide complete information in one page than to allow you to read ten pages of documents to find all the interfaces of A type implementation.

Why do some tools, such as reflector or object browsers, display all interfaces?

These tools do not know what the source code looks like. They can only start with metadata. Because explicit declaration of all interfaces is only optional, these tools do not know whether the source code explicitly declares all interfaces. It may be wrong to display all the information, so these tools are better to list the information comprehensively. These tools show youThere may be more information than the actual situationInsteadHide information you may needThey want to help you.

I found that ienumerable <t> inherits from ienumerable, but ilist <t> does not inherit from ilist. What is the problem?

This is because ienumerable <t> is covariant while ilist <t> is not covariant. Through packing, we can treat an integer sequence as an object sequence. However, a readable and writable integer list cannot be treated as a list of readable and writable objects, because you may add a string to the readable and writable Object List. The ienumerable <t> type can easily meet the requirements of ienumerable. You only need to add a boxed helper method. However, the implementation of the ilist <t> type does not necessarily meet the ilist, so the ilist does not inherit from the ilist.

Why does list <t> implement ilist again?

This is a bit strange, because the list <t> does not meet the ilist requirements except when T is an object. This may be because it is convenient for people who want to upgrade the old C #1.0 code to make it easier for them to use generics. Those who want to upgrade the code may have ensured that only objects of the correct type are added to the list. In most cases, when you pass an ilist as a parameter, the called method only accesses the list by index, instead of adding any type of objects to the list.