FXCOP - CA1034 Error - ¿Por qué?

Question

Estoy ejecutando análisis de código estático con FXCOP 1.36 y sigo recibiendo Advertencia CA1034: Nestado dePessHouldBevisible.

Entiendo que si la clase matriz se declaró interna o privada, pero es pública. ¿Por qué sería malo que Timerreset fuera declarado público?

¿Me estoy perdiendo algo, o es esto algo que se puede ignorar?

¡Gracias por cualquier aporte!

Aquí hay un extracto del código que causa esta advertencia:

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

En términos generales, los tipos anidados son más difíciles de "descubrir".

Por ejemplo, para usar su tipo anidado, tendré que escribir siguiendo

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

Aunque anterior es un código C# válido, no se lee como el uso de tipo habitual.

Los tipos anidados generalmente se usan cuando desea definir un tipo que se use internamente y evitaría el código como anteriormente. Esta es la razón por la cual FXCOP le está dando advertencia. Si quieres, puedes ignorarlo. Personalmente, mantendría mis tipos anidados como privados. Si espero que la persona que llame utilice el tipo, los moveré a un espacio de nombres adecuado.

Answer 2

Es porque su delegado es un tipo, pero se define dentro de la clase de página. Simplemente lo definiría en el espacio de nombres de la compañía. Si estuvieras escribiendo una API, solo lo haría un poco desordenado, eso es todo.

Además, es un poco extraño devolver al delegado así, pero supongo que realmente no sé qué estás tratando de lograr.

Answer 3

¿Por qué sería malo que Timerreset fuera declarado público?

Exactamente como el Descripción Estados:

Los tipos anidados son útiles para encapsular los detalles de implementación privada del tipo de contenido. Utilizado para este propósito, los tipos anidados no deben ser visibles externamente.

Ya que estás exponiendo TimerResetDelegate públicamente con TimerReset, Supongo que no es un detalle de implementación.

No use tipos anidados visibles externamente para la agrupación lógica o para evitar colisiones de nombres; En su lugar, use espacios de nombres.

Lo que hace que parezca que estás usando un tipo anidado para la agrupación. Como dice FXCOP, use un espacio de nombres.

Los tipos anidados incluyen la noción de accesibilidad de los miembros, que algunos programadores no entienden con claridad.

Ya que TimerResetDelegate es un delegado, esto realmente no se aplica.

Muevete TimerResetDelegate a su propio archivo timeresetdelegate.cs y póngalo en su Company.App.Thing espacio de nombres. Entonces, ya no está anidado.

Por supuesto, sería aún mejor ir con Controlador de eventos en lugar de definir su propio tipo de delegado.

Answer 4

En mi humilde opinión, esta es una regla FXCOP que se puede ignorar.

No hay nada de malo en un nivel de CLR con tener una clase anidada. Es solo una regla de directriz agregada a FXCOP porque los autores sintieron que era menos utilizable o un diseño más pobre que hacer que la clase no sea anidada.

Answer 5

Aparentemente, no le gusta la idea de las clases anidadas, cuando pueden usarse fuera del contexto de su clase de página.

Personalmente, estoy de acuerdo con eso en principio, aunque puedo imaginar algunas excepciones en las que podría ser deseable.