Ramifications de méthodes/propriétés virtuelles

Question

Ola the 'flow!

J'ai utilisé Moq récemment dans mon processus de développement et j'aime ce que je suis capable d'accomplir.

Cependant, je me retrouve à rendre mes méthodes (et propriétés pour la plupart) virtuelles afin que je puisse les remplacer par un faux dans mes tests. En dehors de "vous faites passer outre toutes vos méthodes et propriétés", quelles sont les vraies ramifications de ce plan d'action?

Merci pour votre temps,

Dan

Answer 1

Eh bien, vous empêchez la plupart des types d'optimisations. D'abord, le JITter peut ne pas savoir quelle implémentation va être appelée, (Et il ne peut pas, puisque vous utilisez peut-être un Mock, n'est-ce pas?) Donc, tous ces accesseurs de propriété, qui auraient été inline seront réels appelle maintenant. En ce qui concerne la mise en ligne, les propriétés simples n'ajouteront pas de surcharge réelle au moment de l'exécution. Les propriétés virtuelles ne seront pas intégrées, c'est ce qu'elles font. C'était le côté performance des choses, l'autre problème est que vous ne pouvez pas faire confiance aux propriétés pour fonctionner comme vous pensez qu'elles fonctionnent. Chaque propriété peut être remplacée. Même par vous-même, parce que «cette fois, cela avait vraiment du sens, n'est-ce pas? Vous vous retrouverez donc plus souvent que d'habitude à vérifier l'arborescence des appels pour vérifier quelles implémentations sont applicables au code sur lequel vous travaillez.

Answer 2

Je ne pense pas qu'il y ait de graves conséquences. Les chances de surcharger accidentellement une méthode ou une propriété que vous n'aviez pas prévu sont minces.

Je pense que la possibilité de substituer une classe d'objet à une autre (par exemple un objet fantaisie) est une bonne chose, et pour ce faire, vous avez besoin d'une classe de base avec des méthodes/propriétés virtuelles. Cela me rappelle d'utiliser des classes de base abstraites pour adhérer au Open Closed Principle.