FXCOP - ERREUR CA1034 - Pourquoi?

Question

J'exécute une analyse de code statique avec FXCOP 1.36 et je continue à obtenir AVERTISSEMENT CA1034: NeedTypesshouldnotbevisible.

Je comprendrais si la classe parent était déclarée interne ou privée, mais elle est publique. Pourquoi serait-il mauvais que TimeRreset soit déclaré public?

Est-ce que je manque quelque chose, ou est-ce quelque chose qui peut être ignoré?

Merci pour toute contribution!

Voici un extrait du code provoquant cet avertissement:

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

D'une manière générale, les types imbriqués sont plus difficiles à «découvrir».

Par exemple, pour utiliser votre type imbriqué, je devrai écrire après

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

Même si ci-dessus est un code C # valide, il ne se lit pas comme l'utilisation habituelle de type.

Les types imbriqués sont généralement utilisés lorsque vous souhaitez définir un type à utiliser en interne et que vous évitez le code comme ci-dessus. C'est la raison pour laquelle FXCOP vous donne un avertissement. Si vous le souhaitez, vous pouvez l'ignorer. Personnellement, je garderais mes types imbriqués comme privés. Si je m'attends à ce que l'appelant utilise le type, je les déplacerai vers un espace de noms approprié.

Answer 2

C'est parce que votre délégué est un type, mais il est défini dans la classe de page. Je le définirais simplement dans l'entreprise. Si vous écriviez une API, cela le rendrait un peu désordonné, c'est tout.

De plus, il est un peu étrange de retourner le délégué comme ça, mais je suppose que je ne sais pas vraiment ce que vous essayez d'accomplir.

Answer 3

Pourquoi serait-il mauvais que TimeRreset soit déclaré public?

Exactement comme le Description État:

Les types imbriqués sont utiles pour encapsuler les détails de mise en œuvre privés du type de contenu. Utilisées à cet effet, les types imbriqués ne doivent pas être visibles en externe.

Depuis que vous exposez TimerResetDelegate publiquement avec TimerReset, Je suppose que ce n'est pas un détail d'implémentation.

N'utilisez pas de types imbriqués visibles externes pour le regroupement logique ou pour éviter les collisions de noms; Au lieu de cela, utilisez des espaces de noms.

Ce qui donne l'impression que vous utilisez un type imbriqué pour le regroupement. Comme les états FXCOP, utilisez plutôt un espace de noms.

Les types imbriqués incluent la notion d'accessibilité des membres, que certains programmeurs ne comprennent pas clairement.

Depuis TimerResetDelegate est un délégué, cela ne s'applique pas vraiment.

Déplacer TimerResetDelegate à son propre fichier timeresetdelegate.cs et mettez-le dans votre Company.App.Thing Espace de noms. Ensuite, ce n'est plus imbriqué.

Bien sûr, ce serait encore mieux d'aller avec Gestionnaire d'événements Au lieu de définir votre propre type de délégué.

Answer 4

IMHO, c'est une règle FXCOP qui peut être ignorée.

Il n'y a rien de mal à un niveau CLR avec une classe imbriquée. Il s'agit simplement d'une règle de ligne directrice ajoutée à FXCOP car les auteurs ont estimé qu'il était moins utilisable ou une conception plus faible que de rendre la classe non née.

Answer 5

Apparemment, cela n'aime pas l'idée de classes imbriquées, lorsqu'ils peuvent être utilisés en dehors du contexte de votre classe de page.

Je suis personnellement d'accord avec cela en principe, bien que je puisse imaginer quelques exceptions où cela pourrait être souhaitable.