FxCop - CA1034 Fehler - WARUM?

Question

Ich führe statische Code-Analyse mit FxCop 1.36 und ich bekomme warning CA1034: NestedTypesShouldNotBeVisible.

Ich würde verstehen, wenn die Elternklasse als intern oder privat erklärt wurde, aber es ist öffentlich. Warum wäre es nicht gut, wenn TimerReset für öffentlich erklärt wird?

Fehle ich etwas oder ist das etwas, das ignoriert werden kann?

Danke für jede Eingabe! Hier

ist ein Auszug aus dem Code verursacht diese Warnung:

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

Im Allgemeinen sind verschachtelte Typen schwerer zu "entdecken".

z. Um Ihre verschachtelte Art zu verwenden, werde ich folgendes schreiben

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

Auch über obwohl gültige C# -Code ist, ist es nicht wie die üblichen Typnutzungs liest.

Verschachtelte Typen werden im Allgemeinen verwendet, wenn Sie einen intern zu verwendenden Typ definieren und Code wie oben vermeiden möchten. Dies ist der Grund, warum FxCop Sie warnt. Wenn Sie möchten, können Sie es ignorieren. Persönlich würde ich meine verschachtelten Typen als privat behalten. Wenn ich erwarte, dass der Aufrufer den Typ verwendet, verschiebe ich ihn in einen geeigneten Namensraum.

Answer 2

Es ist, weil Ihre Stellvertretung ein Typ ist, aber es ist in der Page-Klasse definiert. Ich würde es nur im Namespace Company.App.Thing definieren, aber es ist wirklich kein Problem. Wenn Sie eine API schreiben würden, wäre es nur ein bisschen unordentlich, das ist alles.

Auch ist es ein bisschen komisch, den Delegierten so zurückzugeben, aber ich denke, ich weiß nicht wirklich, was Sie erreichen wollen.

Answer 3

IMHO, das ist eine FxCop-Regel, die ignoriert werden kann.

Es ist nichts falsch von einer CLR-Ebene mit einer geschachtelten Klasse. Es ist nur eine Richtlinienregel, die zu FxCop hinzugefügt wurde, weil die Autoren meinten, es sei weniger brauchbar oder ein schlechteres Design, als die Klasse nicht verschachtelt zu machen.

Answer 4

Offenbar mag es die Idee von geschachtelten Klassen nicht, wenn sie außerhalb des Kontexts Ihrer Page-Klasse verwendet werden könnten.

Ich stimme dem grundsätzlich zu, obwohl ich mir einige Ausnahmen vorstellen kann, wo es wünschenswert sein könnte.

Answer 5

Warum wäre es schlecht, wenn TimerReset für öffentlich erklärt wird?

Genau wie die description states:

Verschachtelte Typen sind nützlich für private Implementierungsdetails des enthaltenden Typs kapseln. Zu diesem Zweck sollten verschachtelte Typen nicht von außen sichtbar sein.

Da Sie TimerResetDelegate öffentlich mit TimerReset sind auszusetzen, ich denke, es ist nicht ein Implementierungsdetail.

Verwenden Sie keine extern sichtbaren verschachtelten Typen für logische Gruppierung oder um Namenskollisionen zu vermeiden; Verwenden Sie stattdessen Namespaces.

Es sieht so aus, als ob Sie einen verschachtelten Typ zum Gruppieren verwenden. Wie FxCop angibt, verwenden Sie stattdessen einen Namespace.

Verschachtelte Typen beinhalten den Begriff der Zugänglichkeit von Elementen, die einige Programmierer nicht klar verstehen.

Da TimerResetDelegate ein Delegierter ist, trifft dies nicht wirklich zu.

Verschieben Sie TimerResetDelegate zu seiner eigenen TimeResetDelegate.cs-Datei, und legen Sie es in Ihrem Company.App.Thing Namespace. Dann ist es nicht mehr verschachtelt.

Natürlich wäre es sogar besser, einfach mit EventHandler zu gehen, anstatt einen eigenen Delegattyp zu definieren.