MustInherit et fonctions partagées

Question

Je regarde une classe VB.NET (que je n'ai pas écrite) qui est déclarée MustInherit (abstract en C#, je crois) qui a trois méthodes, qui sont toutes définies comme Shared (static en C#). Il n'y a pas de propriétés ou de champs dans la classe - seulement les trois méthodes. Du point de vue d'OO, cela a-t-il un sens?

Ma pensée est pas, parce qu'en rendant MustInherit, vous dites en substance que vous ne pouvez pas créer une instance de cette classe - vous devez hériter de et créer une instance de la classe dérivée. Mais puisque toutes les méthodes sont partagées, vous ne créerez jamais une instance de la classe parent, donc le MustInherit ne fait rien. Vous pouvez aussi bien pas le marquer comme MustInherit et en hériter juste quand vous le voulez.

Y a-t-il une situation où la création d'une classe est logique?

Answer 1

Comme d'autres l'ont dit, il semble qu'ils voulaient vraiment une classe statique C#. VB équivalent à "static" est "shared", mais vous ne pouvez pas marquer les classes "shared" dans VB. La différence est que quelqu'un pourrait hériter de cette classe et ensuite créer une instance. Les classes statiques C# sont scellées.

Ce que aurait dû faire est d'utiliser Module. Une classe statique VB Module et C# sont pratiquement identiques: les membres sont associés au type plutôt qu'à une instance et vous ne pouvez pas en hériter.

Answer 2

D'un point de vue OO, cela n'a pas beaucoup de sens. Cependant, VB n'a pas le moyen de marquer une classe comme partagée, comme le fait C#. En C#, vous marqueriez probablement cette classe comme static class - le MustInherit a probablement été ajouté pour essayer d'empêcher les gens de créer une instance, même s'il s'agit essentiellement d'une classe statique.

Answer 3

En C# une classe peut être déclarée comme statique (= partagée), et je pense que VB.NET ne permet pas que, si une solution de contournement est marquée abstraite (MustInherit) de sorte qu'il n'a jamais instancié