constructeur Résumé en C#

Question

Possible en double:
Why can’t I create an abstract constructor on an abstract C# class?

Pourquoi je ne peux pas déclarer abstraite un constructeur de ma classe comme ceci:

public abstract class MyClass { 
    public abstract MyClass(int param); 
} 

Answer 1

Les constructeurs s'appliquent uniquement à la classe dans laquelle ils sont définis, c'est-à-dire qu'ils ne sont pas hérités. Les constructeurs de classe de base sont utilisés (vous devez appeler l'un d'entre eux, même si vous appelez celui par défaut automatiquement) mais pas surchargé en dérivant des classes. Vous pouvez définir un constructeur sur une classe de base abstraite - il ne peut pas être utilisé directement, mais peut être appelé en dérivant des classes. Ce que vous ne pouvez pas faire est de forcer une classe dérivée à implémenter une signature de constructeur spécifique.

Il est parfaitement raisonnable d'avoir un constructeur défini, typiquement comme protégé, afin de définir un code de configuration commun pour toutes les classes dérivées. Cela est particulièrement vrai, peut-être, lorsque la classe abstraite fournit un autre comportement par défaut qui repose sur cette configuration. Par exemple:

public abstract class Foo 
{ 
    public string Name { get; private set; } 

    protected Foo(string name) 
    { 
     this.Name = name; 
    } 
} 

public class Bar : Foo 
{ 
    public Bar() : base("bar") 
    { 
     ... 
    } 
} 

Answer 2

Vous pouvez » t le déclarer abstract, mais vous pouvez avoir un constructeur sur votre classe abstraite; il suffit de retirer le mot abstract et de fournir un corps pour cela.

Answer 3

Par définition, la classe ne peut pas être instanciée directement, donc dans un sens, elle est déjà abstraite.

Answer 4

Un constructeur n'est pas une méthode ordinaire. Il a un but spécial, et est donc limité aux caractéristiques du langage qui ont un sens à cet effet. Voir aussi: Why do constructors not return values?

Answer 5

Parce que les constructeurs abstraits ne sont pas pris en charge.

Mais une classe abstraite peut avoir un constructeur.

Answer 6

Quel mal avec ceci:

public abstract class MyClass { 
    protected MyClass(int param) 
    { 
    } 
} 

Dans ce cas, vous obligez toutes les classes dérivées d'appeler le constructeur de classe de base.

Answer 7

Résumé implique virtuel. Un constructeur non défini par défaut ne peut jamais être appelé de manière polymorphe, de sorte que le virtuel et l'abstrait ne sont pas autorisés sur les constructeurs. Si dans une future version de C#, les génériques sont améliorés pour permettre d'appeler des constructeurs non-par défaut via un paramètre de type générique, des appels polymorphes aux constructeurs seraient possibles et des constructeurs virtuels et abstraits pourraient aussi être ajoutés.

Answer 8

Les constructeurs sont plus proches des méthodes statiques que des méthodes "normales". Comme les méthodes statiques, ils peuvent être surchargés, mais pas surchargé. Autrement dit, ils ne sont pas hérités mais peuvent être redéfinis.

public BaseClass 
{ 
    public BaseClass(String s) { ... } 
    public static void doIt (String s) { ... } 
} 

public SubClass extends BaseClass 
{ 
    public SubClass(String s) { ... } 
    public static void doIt (String s) { ... } 
} 

public SubClass2 extends BaseClass 
{ 
} 

new SubClass("hello"); 
SubClass.doIt("hello"); 

new SubClass2("hello"); // NOK 
SubClass2.doIt("hello"); // NOK 

Constructors et méthodes statiques sont dynamiquement jamais distribué (virtuellement) - Vous savez toujours le type de béton instanciation ou la classe concrète de la méthode statique.C'est pourquoi il n'a aucun sens d'avoir constructeur abstrait et méthode statique abstraite. C'est pourquoi vous ne pouvez pas non plus spécifier constructeur et méthode statique dans interfaces.

Vous pouvez même penser constructeur comme méthode usine statique (voir la corresponding pattern):

MyClass obj = new MyClass(); // the way it is 
    MyClass obj = MyClass.new(); // think of it like this 

Le seul cas que je vois où il serait logique de définir constructeur abstrait ou méthode statique abstraite serait si la réflexion est utilisée. Dans ce cas, vous pouvez vous assurer que toute sous-classe redéfinira la méthode ou le constructeur statique correspondant. Mais la réflexion est un autre sujet ...

Note: dans les langages tels que Smalltalk où les classes sont des objets normaux, vous pouvez remplacer la méthode statique et avoir un constructeur abstrait. Mais cela ne s'applique pas à Java car les classes ne sont pas des objets "réguliers" même si vous pouvez les obtenir avec la réflexion.