Por que não há variação genérica para classs no C # 4.0?

Se temos para interfaces, por que não temos também para classs? Qual seria o problema que incorreríamos ao usá-lo?

Suponha que você tivesse uma class C que fosse covariante em T. Como seria sua implementação? T tem que sair apenas. Isso significa que C não pode ter qualquer método que tome um T, qualquer propriedade do tipo T com um setter, ou qualquer campo do tipo T , porque os campos são logicamente iguais aos setters das propriedades; T entra.

Praticamente a única coisa útil que você poderia construir com uma class covariante é algo imutável no que diz respeito a T. Agora, eu acho que seria incrível ter listas e pilhas imutáveis ​​covariantes e outros tipos de class. Mas esse recurso não é tão impressionante que justificaria claramente o gasto maciço em fazer com que o sistema de tipos suportasse nativamente os tipos de class imutáveis ​​covariantes.

Um comentário acima pediu um exemplo de onde isso seria útil. Considere o seguinte esboço:

 sealed class Stack { private readonly T head; private readonly Stack tail; public T Peek() { return head; } public Stack Pop() { return tail; } public Stack(T head, Stack tail) { this.tail = tail; this.head = head; } } static class StackExtensions { public static Stack Push(this Stack tail, T head) { return new Stack(head, tail); } public static bool IsEmpty(this Stack stack) { return stack == null; } } 

Suponha que você tenha classs covariantes. Agora você pode dizer

 Stack strings = null; strings = strings.Push("hello"); strings = strings.Push("goodbye"); Stack objects = strings; objects = objects.Push(123); 

E ei, nós apenas empurramos um inteiro para uma pilha de cordas, mas tudo deu certo! Não há razão para que isso não seja seguro. Uma operação que violaria a segurança de tipo em uma estrutura de dados mutável pode ser covariante com segurança em uma estrutura de dados imutável.

Confira este post msdn: variação em tipos genéricos (guia de programação C #)

A equipe do .NET, juntamente com a equipe do C # e do VB.NET, tem resources limitados, o trabalho que realizaram em co- e contravariância resolve a maior parte do problema do mundo real . Sistemas de tipos são muito complexos para acertar – uma solução que funciona em 99,9999% dos casos não é boa o suficiente se levar a códigos inseguros nos outros casos.

Eu não acho que o custo / tempo de suportar especificações de co-contravariância (por exemplo, “in” / “out”) em methods de class é de um valor suficientemente grande. Eu posso ver muito poucos casos em que eles seriam utilizáveis ​​- devido à falta de inheritance de class múltipla.

Você preferiria ter esperado outros 6 meses pela .net para obter esse suporte?


Outra maneira de pensar nisso é que no .net

  • Interfaces / delegates – são usados ​​para modelar o sistema de tipo conceitual de um aplicativo
  • Classe são usadas para implementar os tipos acima
  • A inheritance de classs é usada para reduzir a duplicação de código enquanto se faz o acima
  • co-e contravariância é sobre o sistema de tipo conceitual de uma aplicação