Действительно ли возможно сделать “этот тип” для дженериков в C#?
Существует интересный ответ на французской статье Википедии для Отражения ( здесь )
, Отражение может анализироваться в двух частях:
- самоанализ: программа может исследовать себя.
- заступничество: программа может изменить свое состояние/значение.
, Таким образом отражение является 'более сильным' свойством, чем самоанализ. Вот почему Вы говорите самоанализ типа для способности знать типы во времени выполнения (и изменение их является другим действием: преобразование/кастинг).
РЕДАКТИРОВАНИЕ: на самом деле я просто понял, что в первом ответе говорилось точно это ^^. Время для отключения меня...
4 ответа
Нет ничего, что могло бы облегчить этот шаблон, и на самом деле шаблон в любом случае не совсем пуленепробиваемый - потому что вы можете иметь:
class TypeA : Adapter<TypeA, string>
class TypeB : Adapter<TypeA, string> // Bug!
Вторая строка здесь полностью допустима - TypeA - допустимый аргумент типа для параметра типа TThis , хотя это не то, что мы хотели. По сути, система типов не позволяет нам выразить концепцию «T должен быть этим типом».
Я не согласен с теми, кто говорит, что это плохой или бесполезный образец. Я нашел его полезным (хотя и сложным) в Protocol Buffers - без него было бы намного хуже. Например:
Foo foo = new Foo.Builder { Name="Jon" }.Build();
не будет работать, если Foo.Build () не будет строго типизирован для возврата Foo ,
Обычно в этом случае вам просто нужно обратиться к базовому классу:
public class Adapter<T> {
public virtual Adapter<T> DoSomething();
Попытка сделать то, что вы '
Если унаследованный метод в производном классе должен возвращать производный тип вместо базового типа (известный как ковариантный тип возвращаемого значения ), это уже поддерживается в C #.
Я тоже возник проблемы с поиском обоснованного использования этого (хотя это интересная идея).
Вы пытаетесь изменить то, как вы ограничиваете общие типы, которые вы можете использовать? Похоже, вы хотите использовать некоторые базовые функции, не зная фактического типа; это то, что интерфейсы для . Предложение where очень удобно для такого рода проблем.
class Dictionary<K, V>
where K : IComparable, IEnumerable
where V : IMyInterface
{
public void Add(K key, V val)
{
}
}
Приведенный выше пример ограничивает K (ключ), так что он должен быть сопоставимым и перечисляемым, а V должен реализовывать любые функции клиента, которые вы хотите, через ваш собственный интерфейс.