Peut-on avoir trop de méthodes «virtuelles protégées»?

Question

Voici une question pour ceux d'entre vous qui ont de l'expérience dans les grands projets et la conception d'API / framework.

Je travaille sur un cadre qui sera utilisé par de nombreux autres projets dans le futur. Je souhaite donc le rendre agréable et extensible, mais il doit en même temps être simple et facile à comprendre.

Je sais que beaucoup de gens se plaignent du fait que le framework .NET contient trop de classes scellées et de membres privés. Devrais-je éviter ces critiques et ouvrir toutes mes classes avec beaucoup de membres virtuels protégés?

Est-ce une bonne idée de rendre autant de méthodes et de propriétés protégées que virtuelles ? Dans quelles situations éviteriez-vous le virtuel protégé et rendiez vos membres privés.

Answer 1

Votre classe comprend des membres de données; les méthodes qui effectuent des opérations internes de base sur les membres de données dont la fonctionnalité ne devrait jamais changer devraient toujours être privées. Ainsi, les méthodes qui effectuent des opérations de base avec vos membres de données, telles que l'initialisation et l'allocation, doivent être privées. Sinon, vous courez le risque de " deuxième commande " classes dérivées obtenant un ensemble incomplet de comportements activés; Les premiers membres dérivés pourraient potentiellement redéfinir le comportement de la classe.

Cela étant dit, je pense que vous devez être très prudent lorsque vous définissez des méthodes comme "protégées par le virtuel". J'utiliserais une grande prudence en définissant les méthodes comme "protégées par le virtuel", car cela ne déclarerait pas seulement la possibilité de remplacer la fonctionnalité, mais définirait, d'une certaine manière, une attente : fonctionnalité remplacée. Cela me semble être un ensemble sous-défini de comportements à remplacer; Je préférerais avoir un ensemble bien défini de comportements à remplacer. Si vous souhaitez avoir un très grand nombre de comportements pouvant être remplacés, je préfère me tourner vers la programmation orientée aspect, qui permet ce genre de chose de manière très structurée.

Answer 2

Lorsque vous marquez une méthode avec le mot virtual, vous autorisez les utilisateurs à modifier la façon dont cette partie de la logique est exécutée. Pour de nombreuses raisons, c'est exactement ce que vous voulez. Je crois que tu le sais déjà.

Cependant, les types doivent être conçus pour ce type d’extension. Vous devez choisir activement les méthodes, où il est logique de laisser l'utilisateur changer le comportement. Si vous vous contentez de claquer virtuellement partout où vous risquez de ruiner l'intégrité du type, cela n'aide pas vraiment l'utilisateur à comprendre le type, et vous pouvez introduire un certain nombre de bogues, y compris des problèmes liés à la sécurité.

Je préfère l'approche conservatrice. Je marque toutes mes classes avec sealed sauf si je souhaite spécifiquement activer l'héritage et dans ces (rares) cas, je ne fais que les méthodes requises virtuelles.

Il est facile de supprimer la balise sealed si la classe doit être modifiée pour permettre l'héritage ultérieurement. Toutefois, si vous souhaitez modifier une classe déjà utilisée comme classe de base pour un autre type, vous risquez de rompre la sous-classe lorsque vous modifiez la classe de base.

Answer 3

Mon point de vue est le suivant:

• Si vous pouvez utiliser événements , sa préférence pour les méthodes protected .
• Essayez d'éviter les méthodes protected , sinon vous devez les utiliser; -).

Answer 4

Le choix de protected sur private est une décision de conception délibérée. Vous déclarez que votre classe prend explicitement en charge l'utilisation de cette fonction, avec tous les frais généraux (effort de conception et de mise en œuvre) qui l'accompagnent. Je n’utiliserais protected que dans les cas où je sais que c’est nécessaire, en grande partie parce que je le fais moi-même. (Vous trouverez également des commentaires de développeurs BCL dans le même sens que ce que j’ai dit.)

La différence de performance virtuel / non virtuel n'est pas pertinente sur les ordinateurs suffisamment puissants pour exécuter le .NET Framework.

Answer 5

Non, vous ne pouvez pas en avoir "trop". Cependant, l’idée selon laquelle nous devrions simplement protéger chaque élément au lieu de tout ce qui est privé ou éviter les expressions "scellées". à tout prix est juste idiot. Je garderais " méthodes auxiliaires " et des structures de données internes privées.

Answer 6

  

Est-ce une bonne idée de créer autant de méthodes et de propriétés que possible virtual virtual ?

Pas aussi bonne idée.

Les méthodes virtuelles protégées fournissent des points d'extensibilité dans la structure tout en ajoutant un couplage.

Il existe des techniques plus prometteuses pour fournir une extensibilité: Composition et Délégation .