Ошибка FxCop - CA1034 - ПОЧЕМУ?

Question

Я запускаю статический анализ кода с помощью FxCop 1.36, и я продолжаю получать warning CA1034: NestedTypesShouldNotBeVisible.

Я бы понял, если родительский класс был объявлен как внутренний или закрытый, но он является общедоступным. Почему было бы плохо, если TimerReset будет объявлен публичным?

Я что-то упускаю, или это то, что можно игнорировать?

Спасибо за любой ввод!

Вот отрывок кода вызывает данное предупреждение:

namespace Company.App.Thing 
{ 
    public partial class Page : XtraPage 
    { 
     public delegate void TimerResetDelegate(object sender, EventArgs e); 
     private TimerResetDelegate _timerReset; 

     public Page() 
     { 
      InitializeComponent(); 
     } 

     public TimerResetDelegate TimerReset 
     { 
      set 
      { 
       if (null != (_timerReset = value)) 
       { 
        checkBox.Click += new EventHandler(_timerReset); 
        textField.Click += new EventHandler(_timerReset); 
        textField.KeyDown += new KeyEventHandler(_timerReset); 
        TimeField.Click += new EventHandler(_timerReset); 
        TimeField.KeyDown += new KeyEventHandler(_timerReset); 
       } 
      } 
     } 
    } 
} 

Answer 1

Вообще говоря, вложенные типы сложнее «обнаружить».

E.g. Для того, чтобы использовать вложенный тип, я должен написать следующее

Page.TimerResetDelegate timer = new Page.TimerResetDelegate(); 

Даже если выше справедливо C# код, он не читает, как использование обычного типа.

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

Answer 2

Это потому, что ваш делегат типа, но он определен в классе страницы. Я бы просто определил его в пространстве имен Company.App.Thing, но это не проблема. Если бы вы писали API, это просто сделало бы его немного грязным, вот и все.

Кроме того, это немного странно, чтобы вернуть делегата, как это, но я думаю, что я действительно не знаю, чего вы пытаетесь достичь.

Answer 3

IMHO, это правило FxCop, которое можно игнорировать.

Нет ничего плохого в уровне CLR с наличием вложенного класса. Это просто правило правил, добавленное к FxCop, потому что авторы считают, что он менее полезен или имеет более плохую конструкцию, чем делает класс не-вложенным.

Answer 4

По-видимому, это не нравится идея вложенных классов, когда они могут использоваться вне контекста вашего класса.

Я лично согласен с этим в принципе, хотя я могу представить некоторые исключения, где это может быть желательно.

Answer 5

Почему было бы плохо, если TimerReset будет объявлен публичным?

Точно как description states:

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

Поскольку вы обнажая TimerResetDelegate с TimerReset публично, я предполагаю, что это не деталь реализации.

Не используйте видимые снаружи видимые типы для логической группировки или во избежание столкновений имен; вместо этого используйте пространства имен.

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

Вложенные типы включают понятие доступности членов, которое некоторые программисты не понимают четко.

С TimerResetDelegate является делегатом, это действительно не применимо.

Переместить TimerResetDelegate в собственный файл TimeResetDelegate.cs и поместить его в ваше пространство имен Company.App.Thing. Затем он больше не вложен.

Конечно, было бы лучше, если бы просто с EventHandler вместо определения собственного типа делегата.