Discussion :

[WebPac]

Bonjour tout le monde,

j'essaie de faire dériver une classe statique d'une autre classe statique, et j'ai l'erreur de compilation suivante CS0713 :

La classe statique 'type statique' ne peut pas dériver du type 'type'. Les classes statiques doivent dériver d'objets.

Avec comme raison :

Si cela était autorisé, la classe statique hériterait des méthodes et des membres non statiques de la classe de base ; elle ne serait donc pas statique. Par conséquent, ce n'est pas autorisé.

Ce qui se justifie pleinement si on essayait de la faire dériver d'une classe non statique mais qui n'a pas de sens si on veut la faire dériver d'une classe de base statique.

[Guulh]

Hello,

étant donné qu'une classe statique ne peut pas contenir de méthodes ou de membres protégés, il ne sert à rien d'en hériter. Puisqu'un éventuel fils aurait accès aux mêmes membres que tous les autres (à savoir les membres publics).

Quel est ton besoin ? pourquoi tes classes sont-elles statiques ? Pourquoi veux-tu faire de l'héritage ?

[WebPac]

Hello,

étant donné qu'une classe statique ne peut pas contenir de méthodes ou de membres protégés, il ne sert à rien d'en hériter. Puisqu'un éventuel fils aurait accès aux mêmes membres que tous les autres (à savoir les membres publics).

C'est parce qu'il ne peut pas y avoir d'héritage qu'elle ne peut pas contenir de méthodes ou membres protégés et non l'inverse.

Quel est ton besoin ? pourquoi tes classes sont-elles statiques ? Pourquoi veux-tu faire de l'héritage ?

J'ai une classe statique dans une ensemble qui possède des membres, propriétés et méthodes statiques qui sert de conteneur de Command pour le ribbon de Microsoft. Cette classe possède tout ce qu'il faut pour fonctionner, mais ne possède pas de Command spécifiques à certains projets.
Puis, j'ai un projet qui possède un ruban et je voudrais déclarer de nouvelles commandes dans ce nouveau projet dans une classe statique qui réutiliserait la première classe statique.
On pourrait le faire en rendant tout ce qui est nécessaire dans la première en public, ce que j'ai fait, puis y accéder via MaClasseStatiqueBase.ProprieteStatique mais je trouve ça embêtant de devoir rendre public toute la mécanique de fonctionnement interne.

[Nathanael Marchand]

C'est parce qu'il ne peut pas y avoir d'héritage qu'elle ne peut pas contenir de méthodes ou membres protégés et non l'inverse.

Non non c'est parcequ'il n'y a pas de membres d'instance que ca ne marche pas d'hériter.

J'ai une classe statique dans une ensemble qui possède des membres, propriétés et méthodes statiques qui sert de conteneur de Command pour le ribbon de Microsoft. Cette classe possède tout ce qu'il faut pour fonctionner, mais ne possède pas de Command spécifiques à certains projets.
Puis, j'ai un projet qui possède un ruban et je voudrais déclarer de nouvelles commandes dans ce nouveau projet dans une classe statique qui réutiliserait la première classe statique.
On pourrait le faire en rendant tout ce qui est nécessaire dans la première en public, ce que j'ai fait, puis y accéder via MaClasseStatiqueBase.ProprieteStatique mais je trouve ça embêtant de devoir rendre public toute la mécanique de fonctionnement interne.

Pourquoi ne pas passer par un genre d'aggregation?

[WebPac]

Non non c'est parcequ'il n'y a pas de membres d'instance que ca ne marche pas d'hériter.

C'est l'histoire du serpent qui se mord la queue.
Je ne vois toujours pas pourquoi il ne peut pas y avoir d'héritage de classes statiques qui puisse accéder aux membres, propriétés et méthodes statiques.

Pourquoi ne pas passer par un genre d'aggregation?

C'est à dire ? Je ne vois pas très bien ce que tu entends par là.

[Nathanael Marchand]

C'est l'histoire du serpent qui se mord la queue.
Je ne vois toujours pas pourquoi il ne peut pas y avoir d'héritage de classes statiques qui puisse accéder aux membres, propriétés et méthodes statiques.


C'est à dire ? Je ne vois pas très bien ce que tu entends par là.

L'héritage concerne uniquement les membres d'instance. Une classe statique ne possède pas de membres d'instance elle ne peut donc pas être héritée.

Pour la sorte d'aggregation il faudrait que tu encapsules la classe statique "de base"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public static class A
{
    public static void Fonc1()
    {
        ...
    }
}
 
//Classe "heritée"
public static class B
{
    public static void Fonc1()
    {
        A.Fonc1();
    }
}

[WebPac]

L'héritage concerne uniquement les membres d'instance. Une classe statique ne possède pas de membres d'instance elle ne peut donc pas être héritée.

Bon c'est pas grave, c'est un dialogue de sourd.
Pourquoi on peut pas ? Réponse : Parce que c'est pas possible.
Je comprends bien que c'est pas possible, mais à part le fait que par principe c'est pour les instances de classes, il n'y a de raison fondamentale pour laquelle ce ne serait pas faisable.

Pour la sorte d'aggregation il faudrait que tu encapsules la classe statique "de base"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public static class A
{
    public static void Fonc1()
    {
        ...
    }
}
 
//Classe "heritée"
public static class B
{
    public static void Fonc1()
    {
        A.Fonc1();
    }
}

Et donc mettre dans la classe A tout en public et remapper dans la classe B, finalement, je vais continuer comme j'ai commencé ça revient au même.

[Nathanael Marchand]

Bon c'est pas grave, c'est un dialogue de sourd.
Pourquoi on peut pas ? Réponse : Parce que c'est pas possible.
Je comprends bien que c'est pas possible, mais à part le fait que par principe c'est pour les instances de classes, il n'y a de raison fondamentale pour laquelle ce ne serait pas faisable.

Ben ne pas coller à la définition d'heritage ca me parait quand même une bonne raison fondamentale! C'est comme essayer de faire rentrer un carré dans un rond.
Admettons que heriter d'une classe statique ca compile, ca t'avancerait a quoi? Car de toute facon les membres de la classe de base ne te serait pas accessible (puisque statique et pas d'instance).

[WebPac]

Ben ne pas coller à la définition d'heritage ca me parait quand même une bonne raison fondamentale! C'est comme essayer de faire rentrer un carré dans un rond.
Admettons que heriter d'une classe statique ca compile, ca t'avancerait a quoi? Car de toute facon les membres de la classe de base ne te serait pas accessible (puisque statique et pas d'instance).

Donc ce n'est pas possible parce que par définition ce n'est pas possible.
C'est un cas non prévu par l'équipe qui développe le C#, mais si un jour, ils décidaient de le faire, il n'y aurait pas de point technique bloquant à sa réalisation.
Il existe d'autres langages objets où c'est tout à fait possible et ça donne des possibilités de programmation qu'on ne peut pas faire sans.

Entre autre, ça m'avancerait dans le sens où je pourrais très bien accéder aux membres, propriétés et méthodes statiques de la classe de base sans avoir à les rendre public.

[Nathanael Marchand]

Donc ce n'est pas possible parce que par définition ce n'est pas possible.
C'est un cas non prévu par l'équipe qui développe le C#, mais si un jour, ils décidaient de le faire, il n'y aurait pas de point technique bloquant à sa réalisation.
Il existe d'autres langages objets où c'est tout à fait possible et ça donne des possibilités de programmation qu'on ne peut pas faire sans.

Entre autre, ça m'avancerait dans le sens où je pourrais très bien accéder aux membres, propriétés et méthodes statiques de la classe de base sans avoir à les rendre public.

Pour rebondir la dessus:

The following list provides the main features of a static class:

• Contains only static members.
• Cannot be instantiated.
• Is sealed.
• Cannot contain Instance Constructors.

D'autre part, pourrais tu me dire, pour ma culture perso, quels languages le permettent? Le C++ et le Java ne possèdent pas le concept de classes statiques! C'est encore moins possible d'en hériter

[WebPac]

Pour rebondir la dessus:


D'autre part, pourrais tu me dire, pour ma culture perso, quels languages le permettent? Le C++ et le Java ne possèdent pas le concept de classes statiques! C'est encore moins possible d'en hériter

Oui, je sais qu'elle est sealed par définition, on continue à tourner en rond.
Pourquoi on peut pas ? Parce que par définition on peut pas.

C'est en Delphi, on peut le faire, mais ils sont allés encore bien plus loin dans le concept, car on peut déclarer des références de classes, pas des références statiques, mais des références de classes, c'est à dire, qu'on peut déclarer une référence qui ne va pas pointer vers une instance mais vers une classe directement.
Du coup, on obtient toute la logique héritage non plus seulement sur les instances de classes mais aussi sur les classes elles mêmes. Il est donc possible par exemple de déclarer des méthodes statiques virtuelles et override.
Et c'est très pratique et très simple pour faire des fabriques abstraites par exemple.

[Guulh]

Re-hello,
on tourne effectivement en rond, mais dans ton post initial, tu connaissais la question et la réponse, il n'y a pas tellement de marge pour la discussion
C# décourage l'utilisation du mot clé static, comme tu le constates, en n'incluant pas des fonctionnalités proposées par Delphi. Le plus simple, si tu veux vraiment avoir quelque chose qui ressemble à de l'héritage tout en étant accessible de partout, est de recourir à un singleton. C'est tout aussi pratique, c'est bien plus testatble, et c'est aussi accessible dans le code que des méthodes statiques.
Au passage, le concepteur principal de C# est aussi celui de delphi; si cette possibilité n'est pas offerte, c'est qu'il a dû considérer qu'elle n'est pas nécessaire, voire non souhaitable. (je ne peux que supputer, bien sûr)
Un problème fréquent lors de la conception d'un ensemble de classes est le choix enter composition et héritage. le comportement partagé par tes classes statiques ne peut-il pas être isolé dans une autre classe ?

[WebPac]

Re-hello,
on tourne effectivement en rond, mais dans ton post initial, tu connaissais la question et la réponse, il n'y a pas tellement de marge pour la discussion

En effet, je n'aurais pas dû ouvrir ce topic, mais j'aurais dû directement écrire à Microsoft pour qu'il rajoute cette fonctionnalité dans C# 5.0 ou tout du moins entamer un dialogue sur le pour et le contre.

C# décourage l'utilisation du mot clé static, comme tu le constates, en n'incluant pas des fonctionnalités proposées par Delphi. Le plus simple, si tu veux vraiment avoir quelque chose qui ressemble à de l'héritage tout en étant accessible de partout, est de recourir à un singleton. C'est tout aussi pratique, c'est bien plus testatble, et c'est aussi accessible dans le code que des méthodes statiques.
Au passage, le concepteur principal de C# est aussi celui de delphi; si cette possibilité n'est pas offerte, c'est qu'il a dû considérer qu'elle n'est pas nécessaire, voire non souhaitable. (je ne peux que supputer, bien sûr)
Un problème fréquent lors de la conception d'un ensemble de classes est le choix enter composition et héritage. le comportement partagé par tes classes statiques ne peut-il pas être isolé dans une autre classe ?

En effet et on trouve un certain de point communs entre les 2 technos et je ne vois pas pourquoi ils ne l'ont pas fait à part que le besoin n'est pas énorme pour les développeurs.

Faire un singleton alourdit le code et même si le mot clé static n'est pas recommandé, en WPF lorsqu'on veut faire du binding, il est souvent plus simple de binder des propriétés statiques plus que des instances, surtout aussi côté designer.

[MetalGeek]

Salut,
pour moi une "classe statique" c'est en fait un gadget rajouté aux langages C# et Java (et peut-être d'autres, je ne sais pas).
Ça n'a aucun intérêt d'être dans la conception objet - justement parce que ça ne créé pas d'objets ! Ça les manipule, en fait ça sert de librairie de fonctions, ou de conteneur, etc. Donc comme ça n'a rien à voir avec les processus objet, pourquoi on pourrait la faire hériter ?? L'héritage n'a de sens que dans une sémantique objet. La bonne solution est, je pense, comme dit plus haut, l’agrégation. Il ne faut pas oublier qu'à la base, l'héritage s'utilise si c'est justifié, ce qui ne me semble pas être le cas dans le problème évoqué puisqu'on peut faire autrement.

[Guulh]

Salut,
pour moi une "classe statique" c'est en fait un gadget rajouté aux langages C# et Java (et peut-être d'autres, je ne sais pas).
Ça n'a aucun intérêt d'être dans la conception objet - justement parce que ça ne créé pas d'objets !

Tu confonds cause et conséquence Les classe statiques en C# ne sont utilisées que comme des collections de méthodes (comme les méthodes libres dans un langage comme C++ qui n'est pas uniquement objet) parce qu'elles ne permettent rien de plus.

Ce n'est pas parce qu'on y est pas habitué que ça n'a pas de sens... Ca existe en Delphi, c'est donc que c'est concevable. Singleton et classe entièrement statique ont pas mal de points communs, il est compréhensible de fournir des fonctionnalités au langage permettant de se passer de l'un au profit de l'autre. Après, comme je disais, les concepteurs de C# ont préféré s'en passer, considérant probablement que le surcoût en terme de complexité du langage, de docs et spécifications à fournir, ... ne valait pas la peine.

[MetalGeek]

Je me suis mal exprimé. Ce que je voulais dire, c'est qu'une classe "static" ne représente pas quelque chose de nouveau, quelque chose de particulier, qui serait irremplaçable dans le langage. En fait c'est une classe normale dans laquelle on ne mettrait que des membres "static", le fait de faire la classe "static" elle-même interdit juste au niveau de la compilation de déclarer des membres d'instance (ou d'hériter donc).

en fait ça sert de librairie de fonctions

Les classe statiques en C# ne sont utilisées que comme des collections de méthodes

=> ben tu vois, on est d'accord, non ..?

En fait j'ai même l'habitude de les utiliser. Ce que je voulais souligner c'est le fait qu'il soit normal qu'on ne puisse pas en hériter ou les faire hériter (sinon, tant qu'à faire, on a qu'à pouvoir mettre des membres protégés, etc... et où sera la différence avec une classe non 'static' ?)

[WebPac]

Salut,
pour moi une "classe statique" c'est en fait un gadget rajouté aux langages C# et Java (et peut-être d'autres, je ne sais pas).
Ça n'a aucun intérêt d'être dans la conception objet - justement parce que ça ne créé pas d'objets !

Ca ne fait toujours pas avancer le shimblick. Ca n'est pas possible parce que par définition ce n'est pas prévu, mais tu n'expliques pas pourquoi ce n'est pas prévu.
On dit qu'en C# tout est objet, même une classe est au final un objet de la class Class.
De plus, on peut accéder à la classe comme objet typé en 'Type' via la réflexion et GetType.

L'héritage n'a de sens que dans une sémantique objet.

Parce qu'on l'a définit ainsi, mais pourquoi ne pourrait-on pas le définir autrement ?

La bonne solution est, je pense, comme dit plus haut, l’agrégation. Il ne faut pas oublier qu'à la base, l'héritage s'utilise si c'est justifié, ce qui ne me semble pas être le cas dans le problème évoqué puisqu'on peut faire autrement.

Il existe toujours plusieurs solutions à un problème, ce n'est pas parce qu'on peut faire autrement que ça justifie qu'on ne puisse pas le faire.

En fait j'ai même l'habitude de les utiliser. Ce que je voulais souligner c'est le fait qu'il soit normal qu'on ne puisse pas en hériter ou les faire hériter (sinon, tant qu'à faire, on a qu'à pouvoir mettre des membres protégés, etc... et où sera la différence avec une classe non 'static' ?)

Et pourquoi si on pouvait en hériter on ne pourrait pas mettre des membres statiques protégés ?
La différence serait qu'on ne pourrait pas faire d'instance de classe 'static' et que dans une classe 'static', on ne pourrait pas déclarer de membres, propriétés ni méthodes d'instances mais uniquement 'static', c'est d'ailleurs la définition d'une classe 'static' alors que le fait qu'elle soit 'sealed' n'est qu'une conséquence des limitations imposées par le langage.

Singleton et classe entièrement statique ont pas mal de points communs,

Exact, d'ailleurs si le singleton est typé d'une classe non héritée, autant utiliser une classe statique, on ne s'embête pas à devoir gérer le constructeur, instanciation, accès au singleton...

[MetalGeek]

Ca ne fait toujours pas avancer le shimblick. Ca n'est pas possible parce que par définition ce n'est pas prévu, mais tu n'expliques pas pourquoi ce n'est pas prévu.

Bon. Essayons autrement.

Quel est l'interêt de l'héritage (je ne parle pas de l'héritage d'implémentation, mais de l'héritage utile aux niveaux conceptuel et sémantique) :
J'ai une classe A. B dérive de A, et C dérive de A aussi. Un code client est conçu pour utiliser des objets de type A. Grâce à l'héritage, je peux lui fournir des références indifféremment de A, B ou C (enfin, indifféremment, au niveau validation de compilation du moins).
Qu'est-ce qui saute aux yeux là-dedans ? référence. Qui dit référence, dit instance. Donc classe non statique. Exemple à deux balles avec un faux singleton :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
 
public static class DataFacade
{
    public static readonly DataProviderBase ProviderInstance = new XmlDataProvider();
}
 
public abstract class DataProviderBase
{
    public abstract IEnumerable<MonDataType> GetData();
}
 
internal sealed class XmlDataProvider : DataProviderBase
{
    public override IEnumerable<MonDataType> GetData()
    {
          //je créé des objets avec des données XML  
    }
}
 
internal sealed class SqlDataProvider : DataProviderBase
{
    public override IEnumerable<MonDataType> GetData()
    {
          //je créé des objets avec des données SQL
    }
}

Après, c'est sûr qu'on peut discuter pendant des lustres, mais je fais quand même confiance à l'équipe Microsoft pour savoir ce qu'ils font... Tu restes libre d'envoyer une requête ou des propositions d'évolution du C# sur leurs threads (je dis cela sans ironie, il y a des sections prévues pour).
C'est juste que même en cherchant bien, je n'arrive pas à trouver l'once de l'ombre d'un début de piste pour me faire imaginer l'utilité de l'héritage dans les classes 'static'.

[WebPac]

Dans ton exemple, ce serait pratique si en plus de l'héritage de classe statique, on pouvait aussi avoir accès aux références de classe, d'ailleurs une fonctionnalité ne va pas sans l'autre.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
public abstract static class DataProviderBase
{
    public abstract static IEnumerable<MonDataType> GetData();
}
 
internal sealed static class XmlDataProvider : DataProviderBase
{
    public override static IEnumerable<MonDataType> GetData()
    {
          //je créé des objets avec des données XML  
    }
}
 
internal sealed static class SqlDataProvider : DataProviderBase
{
    public override static IEnumerable<MonDataType> GetData()
    {
          //je créé des objets avec des données SQL
    }
}
 
// ....
internal static class Test
{
    public static Main()
    {
        TypeDataProviderBase ref = XmlDataProvider;
        ref.GetData();
    }
}

Un autre cas d'utilisation, une interface permet de définir un contrat, une obligation de d'implémentation de méthodes et propriétés. Si tu fais une interface, c'est que tu veux que ceux qui l'implémentent soient obligés d'avoir certaines propriétés et méthodes, mais tu ne peux pas leur imposer des méthodes et propriétés statiques car on ne peut rien mettre en statique abstrait dans une interface, ce qui simplifierait l'implémentation du Design Pattern Fabrique Abstraite.

[hegros]

WebPac, ce que dis PitMaverick78 et MetalGeek est totalement correct en POO, c'est toi qui a manifestement un problème pour comprendre ce qu'est l'héritage.

Le polymorphisme ne s'applique qu'aux instances de classes et c'est cette conception de l'objet qui en fait découler que par définition une class statique ne peut pas utiliser le polymorphisme car une classe statique n'a pas d'instance par définition donc on ne peut pas appliquer la conception oo, le polymorphisme, dessus.

En plus comment tu feras

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
static class A 
{
 public static void toto() {}
}
 
static class B : A
{
 
}
 
main()
{
   B.toto() ; 
}

Quel intêret puisque la liaison(ligature) est static autant faire A.toto() il ne s'agit pas d'objets différents c'est toujours la même classe.

La différence fondamentale réside vraiment dans la notion qui différencie une classe et une instance de classe.

En fait qu'est-ce qui t'oblige dans ton dernier exemple de mettre static partout ? Ce n'est pas nécessaire sans avec des objets cela marcherait tout autant..