• Jobs
  • About Us
  • professionals
    • Home
    • Jobs
    • Courses and challenges
  • business
    • Home
    • Post vacancy
    • Our process
    • Pricing
    • Assessments
    • Payroll
    • Blog
    • Sales
    • Salary Calculator

0

269
Views
¿Por qué IList<T> solo hereda de ICollection<T>?

Curiosamente, cuando voy a la definición de IList<T> en Visual Studio, no es lo mismo que el código fuente en GitHub.

ingrese la descripción de la imagen aquí

IList<T>

 public interface IList<T> : ICollection<T>, IEnumerable<T>, IEnumerable

ICollection<T>

 public interface ICollection<T> : IEnumerable<T>, IEnumerable

Dado que ICollection<T> ya incluye IEnumerable<T> e IEnumerable , ¿por qué IList<T> necesita incluirlos? ¿No podría simplificarse como se muestra a continuación?

 public interface IList<T> : ICollection<T>

Estoy tratando de entender una lógica detrás de este largo encadenamiento de interfaz.

Puede consultar el código fuente a continuación para ver las diferencias.

https://github.com/microsoft/referencesource/blob/5697c29004a34d80acdaf5742d7e699022c64ecd/mscorlib/system/collections/generic/ilist.cs#L37

about 3 years ago · Santiago Trujillo
1 answers
Answer question

0

TL; DR : el compilador compilará la clase como si implementara específicamente todas las interfaces mencionadas , así como todas las interfaces implícitas/heredadas en el ensamblaje. No hay forma de que ILSpy, ILDasm o "Ir a definición" sepan la diferencia sin descargar y mostrar el código fuente original.


Como ahora ha aclarado que usó Ir a definición en Visual Studio, hay dos herramientas en el alcance:

  • ILSpy
  • ILDasm

Ambos adoptan diferentes enfoques para mostrar el contenido de un ensamblado compilado. Creo que ILSpy se usa detrás de escena en Visual Studio, pero siga leyendo para saber por qué eso en realidad no importa.

Si hacemos una prueba sencilla en LINQPad :

 void Main() { } public interface IA { } public interface IB : IA { } public class Test : IB { }

y luego pida a LINQPad que refleje el código usando ILSpy, obtenemos esta definición para Test :

 public class Test: IB, IA

Claramente, ILSpy muestra que Test implementa ambos, mientras que la fuente acaba de obtener IA a través de IB .

¿Qué pasa con ILDasm? Escribí un ensamblado de .NET 5 con Visual Studio y luego lo descompilé con ILDasm, exactamente con el mismo código que el anterior:

 .class interface public abstract auto ansi ClassLibrary3.IA { } // end of class ClassLibrary3.IA .class interface public abstract auto ansi ClassLibrary3.IB implements ClassLibrary3.IA { } // end of class ClassLibrary3.IB .class public auto ansi beforefieldinit ClassLibrary3.Test extends [System.Runtime]System.Object implements ClassLibrary3.IB, ClassLibrary3.IA {

Básicamente, este es un artefacto de cómo el compilador compila la fuente. No sé suficiente IL para saber si volver a ensamblar la interfaz desde Intermediate Language, sin mencionar que IA en realidad producirá el mismo resultado, pero lo dejaré como ejercicio.

También eché un vistazo a varias fuentes para obtener esta información:

  1. La fuente de referencia no enumera explícitamente las interfaces implícitas
  2. La fuente de Github no enumera explícitamente las interfaces implícitas
  3. La documentación para IList no, pero para IList<T> sí .
  4. ILSpy descompila enumerando todas las interfaces
  5. ILDasm descompila la lista de todas las interfaces (y se supone que este es el contenido real , así que diría que no hay forma de notar la diferencia en el nivel de ensamblaje compilado)
about 3 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Our process Sales
Legal
Terms and conditions Privacy policy
© 2025 PeakU Inc. All Rights Reserved.

Andres GPT

Recommend me some offers
I have an error