Как передать тип методу - Аргумент типа по сравнению с дженериками

У меня не возникнет проблем с подавлением этого предупреждения. Для начала эквивалент в собственном коде MS - Activator.CreateInstance ()

public static T CreateInstance<T>()

Это означает, что правило анализа должно учитывать, покрывается ли тип возврата метода универсальным параметром ...

Это уже упоминалось во многих местах раньше:

• CA1004 не всегда подходит
• FxCop Microsoft.Design и общие выходы

И в правиле были предыдущие ошибки, например:

public static void GenericMethod<T>(List<T> arg);

ранее вызывала его ( исправлено в 2005 SP1 ).

Я предлагаю зарегистрировать ошибку подключения для вашего конкретного примера

Я считаю, что вы неправильно понимаете то, что вам сообщает FxCop, вероятно, потому, что его формулировка не идеальна. Это означает, что универсальный метод должен предоставлять параметр, который относится к этому типу , а не то, что общий метод должен иметь неуниверсальную перегрузку, которая предоставляет среду выполнения Тип пример. Например,

public void DoSomething<T>(T myParam);

myParam - это тип параметра, на который он ссылается. Причина, по которой он этого хочет, - это, как вы предполагаете, для вывода. Это позволяет вам делать что-то вроде ...

string foo = "bar";

DoSomething(foo);

вместо того, чтобы писать

DoSomething<string>(foo);

. В вашем случае можно подавить предупреждение, поскольку вы хотите, чтобы пользователь явно указывал тип. Я бы предложил, однако (при условии, что ваши конструкторы не имеют параметров) вы измените свой where на , где T: SomeBaseClass, new () . Это означает, что он будет указывать компилятору требовать, чтобы любой переданный тип имел конструктор без параметров. Это также означает, что вы можете использовать new T () в своем коде.

FxCop выдаст это предупреждение, даже если вы используете параметр универсального типа в одном или нескольких аргументах, если он не «вырезан»:

public void LinkedList<T> Slice<T>(LinkedList<T> collection, Predicate<T> match)
{
    ...
}

По крайней мере, сработало правило CA1004 "по ошибке" здесь на днях в методе с этой сигнатурой.

Я не уверен, что правила лучше, чем команда FxCop, в том, что правила могут правильно определять код во всех случаях, вот что такое уровень уверенности для:)

Лично меня больше всего беспокоит предупреждение в Fxcop.

Вы, кажется, знаете, что делаете, почему какое-то автоматизированное программное обеспечение знает лучше?

Ну, это не может, это предположение.

Второй подход даже не эквивалентен первому. Во втором вам буквально дается тип, но вы не можете создать экземпляр объекта этого типа (если вы не используете Reflection --- eeek!), И вы должны явно объявить возвращаемый тип (что противоречит цели дженериков для начнем с).

См. это примечание о его подавлении. Похоже, подавление - это нормально.

РЕДАКТИРОВАТЬ: А теперь еще одна идея. Что, если вы изменили его на параметр out и не вернули его через возвращаемую переменную? Удалит ли он предупреждение?

public void MagicMethod<T>( out T retVar ) where T: SomeBaseClass
{
    // Magic goes here
}

Прежде всего, это предупреждение просто для того, чтобы убедиться, что вызывающие абоненты все делают осознанно. Вы можете вызвать свой метод без передачи какого-либо параметра типа, потому что компилятор заранее знает тип объекта. FxCop говорит вам, что это должно быть неявным, чтобы синтаксис для использования общих и неуниверсальных перегрузок выглядел идентичным (я не согласен с этим принципом, но здесь это личное и не имеет отношения к делу).

Во-вторых, ваш второй метод нанесет больший ущерб чем вы можете думать прямо сейчас. Здесь нет проверки типа во время компиляции, поэтому будьте осторожны с исключениями недопустимого приведения во время выполнения, если вы ее используете.