Pourquoi je ne peux pas avoir des méthodes statiques abstraites en C #?

Question

J'ai beaucoup travaillé avec des fournisseurs ces derniers temps et je suis tombé sur une situation intéressante où je voulais avoir un cours abstrait avec une méthode statique abstraite. J'ai lu quelques articles sur le sujet, et cela a du sens, mais y a-t-il une explication claire?

Answer 1

Les méthodes statiques ne sont pas instancié en tant que tels, ils sont disponibles sans une référence d'objet.

Un appel à une méthode statique est fait par le nom de la classe, et non par l'intermédiaire d'un objet de référence, et le IL code pour appeler appeler la méthode abstraite, par le nom de la classe qui la définit, pas nécessairement le nom de la classe utilisée.

Laissez-moi vous montrer un exemple.

Avec le code suivant:

public class A

Si vous appelez B. Test, comme ceci:

Ensuite le code à l'intérieur de la méthode main est comme suit:

{

Comme vous pouvez le voir, l'appel est fait à A. Test, parce que c'était la classe qui la définit, et de ne pas B. Test, même si vous pouvez écrire le code de cette façon.

Si vous aviez types de classe, comme à Delphes, où vous pouvez faire une variable faisant référence à un type et non pas un objet, vous auriez plus d'utiliser pour virtual et donc abstrait des méthodes statiques (et aussi les constructeurs), mais ils ne sont pas disponibles et donc les appels statiques sont non-virtuel .NET.

Je me rends compte qu'IL les concepteurs peuvent autoriser le code à compiler pour appeler B. Test, et de résoudre l'appel à l'exécution, mais ce ne serait pas encore virtuel, que vous auriez encore à écrire une sorte de nom de classe.

Méthodes virtuelles, et donc abstraite, ne sont utiles lorsque vous êtes en utilisant une variable qui, au moment de l'exécution, peut contenir beaucoup de différents types d'objets, et vous souhaitez appeler la bonne méthode pour l'objet que vous avez dans la variable. Avec des méthodes statiques, vous devez passer par un nom de classe de toute façon, donc la méthode à appeler est connu au moment de la compilation, car il ne peut pas et ne change pas.

Ainsi, virtuel/abstrait des méthodes statiques ne sont pas disponibles dans .NET.

Answer 2

Les méthodes statiques ne peuvent pas être héritée ou remplacées, et c'est pourquoi ils ne peuvent pas être abstraite. Depuis les méthodes statiques sont définis sur le mode de l'instance, d'une classe, ils doivent être appelés explicitement sur ce type. Ainsi, lorsque vous voulez appeler une méthode sur un enfant de la classe, vous avez besoin d'utiliser son nom pour l'appeler. Cela rend l'héritage hors de propos.

Supposons que vous pourrait, pour un moment, héritent des méthodes statiques. Imaginez ce scénario:

public static class Base

Si vous appelez de la Base.GetNumber(), méthode qui serait appelé? La valeur de retour? Son assez facile de voir que, sans la création d'instances d'objets, l'héritage est plutôt dur. Méthodes abstraites sans héritage sont juste des méthodes qui n'ont pas de corps, donc ne peut pas être appelé.

Answer 3

Un autre répondant (McDowell) a déclaré que le polymorphisme ne fonctionne que pour les instances d'objets. Cela devrait être qualifié; Il existe des langages qui traitent les classes comme des instances de type "Class" ou "Metaclass". Ces langages prennent en charge le polymorphisme pour les méthodes d'instance et de classe (statique).

C #, comme Java et C ++ avant lui, n’est pas un tel langage; Le mot clé static est utilisé explicitement pour indiquer que la méthode est liée statiquement plutôt que dynamique / virtuelle.

Answer 4

Pour ajouter aux explications précédentes, les appels de méthodes statiques sont liés à une méthode spécifique à la compilation , ce qui exclut plutôt le comportement polymorphe.

Answer 5

Nous avons fait remplacer les méthodes statiques (en delphi), c'est un peu moche, mais il fonctionne très bien à nos besoins.

Nous l'utilisons donc les classes peuvent avoir une liste des objets disponibles sans la classe, par exemple, nous avons une méthode qui ressemble à ceci:

class function AvailableObjects: string; override;
begin
  Result := 'Object1, Object2';
end;

C'est laid, mais nécessaire, de cette façon, nous pouvons instancier juste ce qui est nécessaire, au lieu d'avoir toutes les classes instantianted simplement à la recherche pour les objets disponibles.

C'était un simple exemple, mais l'application elle-même est une application client-serveur qui dispose de toutes les classes disponibles dans un serveur et plusieurs clients qui pourraient ne pas avoir besoin de tout le serveur a et n'aura jamais besoin d'une instance de l'objet.

Donc, c'est beaucoup plus facile à entretenir que d'en avoir un autre serveur d'application pour chaque client.

Espérons que l'exemple était clair.