FXCOP - CA1034 -Fehler - Warum?

Question

Ich führe eine statische Codeanalyse mit FXCOP 1.36 durch und bekomme immer wieder Warnung CA1034: NestedTypessHouldnotbevisible.

Ich würde verstehen, wenn die Elternklasse als intern oder privat erklärt würde, aber sie ist öffentlich. Warum sollte es schlecht sein, dass Timerreset für öffentlich erklärt wird?

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

Danke für jede Eingabe!

Hier ist ein Auszug des Code, der diese Warnung verursacht:

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.

ZB, um Ihren verschachtelten Typ zu verwenden, muss ich folgen schreiben

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

Auch wenn oben gültig C# Code ist, liest er nicht wie die übliche Nutzung vom Typ.

In der Regel werden verschachtelte Typen verwendet, wenn Sie einen Typ definieren möchten, der intern verwendet werden soll, und Sie würden Code wie oben vermeiden. 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 halten. Wenn ich erwarte, dass Anrufer den Typ nutzt, werde ich sie in einen richtigen Namespace verschieben.

Answer 2

Es liegt daran, dass Ihr Delegierter ein Typ ist, aber in der Seitenklasse definiert ist. Ich würde es einfach in der Firma definieren. App.Thing Namespace, aber es ist wirklich kein Problem. Wenn Sie eine API schreiben würden, würde sie sie nur ein bisschen chaotisch machen, das ist alles.

Außerdem ist es ein bisschen seltsam, den Delegierten so zurückzugeben, aber ich glaube, ich weiß nicht wirklich, was Sie erreichen wollen.

Answer 3

Warum sollte es schlecht sein, dass Timerreset für öffentlich erklärt wird?

Genau wie das Beschreibung States:

Verschachtelte Typen sind nützlich, um private Implementierungsdetails des enthaltenden Typs zu verkörpern. Für diesen Zweck verwendet, sollten verschachtelte Typen nicht extern sichtbar sein.

Da du dich enthüllt TimerResetDelegate öffentlich mit TimerReset, Ich denke, es ist kein Implementierungsdetail.

Verwenden Sie keine extern sichtbaren verschachtelten Typen für die logische Gruppierung oder zur Vermeidung von Namenskollisionen. Verwenden Sie stattdessen Namespaces.

Dies lässt es so aussehen, als hätten Sie einen verschachtelten Typ zum Gruppieren. Verwenden Sie stattdessen einen Namespace.

Zu den verschachtelten Typen gehört der Begriff der Zugänglichkeit von Mitgliedern, die einige Programmierer nicht klar verstehen.

Seit TimerResetDelegate Ist ein Delegierter, das gilt nicht wirklich.

Bewegen TimerResetDelegate an seine eigene Timeresetdelegate.cs -Datei und geben Sie sie in Ihre Company.App.Thing Namespace. Dann ist es nicht mehr verschachtelt.

Natürlich wäre es noch besser, einfach mitzumachen EventHandler Anstatt Ihren eigenen Delegierten -Typ zu definieren.

Answer 4

IMHO, dies ist eine FXCOP -Regel, die ignoriert werden kann.

Es ist nichts Falsches von einer CLR -Ebene mit einer verschachtelten Klasse. Es handelt sich nur um eine Richtlinienregel, die FXCOP hinzugefügt wurde, da die Autoren der Meinung waren, dass sie weniger verwendbar oder ein schlechteres Design war, als die Klasse nicht Nestned zu machen.

Answer 5

Anscheinend mag es nicht die Idee verschachtelter Klassen, wenn sie außerhalb des Kontextes Ihrer Seitenklasse verwendet werden.

Ich persönlich stimme diesem Prinzip zu, obwohl ich mir einige Ausnahmen vorstellen kann, bei denen es wünschenswert sein könnte.