Discussion :

[maa]

Bonjour,

J'ai une classe partielle static dont je ne peux pas modifier le code. J'aimerais enrichir cette classe en définissant une autre partie de cette classe. J'aimerais initialiser certaines propriétés de cette classe dans le constructeur static, mais je ne peux pas définir un tel constructeur dans ma partie car il existe déjà un constructeur static dans la partie de la classe dont je ne peux pas modifier le code. Comment faire alors pour initialiser mes propriété lors de la première utilisation de cette classe ? Peut-on définir des constructeurs "Partiels" ?

Merci d'avance pour votre aide.

[smyley]

Peut-on définir des constructeurs "Partiels" ?

Non je ne crois pas ( et puis si c'était possible, le code aurai été encore plus délirant ) par contre tu peut procéder, par exemple, comme suit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
static class MaClass
{
  static MonObjet objet = null;
  public static MonObjet Objet
  {
    get {
    if(objet = null)
      InitialiseMonObjet();
    return objet;
    }
  }
}

[Bluedeep]

Bonjour,

J'ai une classe partielle static dont je ne peux pas modifier le code. J'aimerais enrichir cette classe en définissant une autre partie de cette classe. J'aimerais initialiser certaines propriétés de cette classe dans le constructeur static, mais je ne peux pas définir un tel constructeur dans ma partie car il existe déjà un constructeur static dans la partie de la classe dont je ne peux pas modifier le code. Comment faire alors pour initialiser mes propriété lors de la première utilisation de cette classe ? Peut-on définir des constructeurs "Partiels" ?

Euh .... déjà, sans préjuger de la solution, la description du problème respire l'embrouille de première classe

Les classes partielles, ok, ça permet de ne pas mélanger le code généré par le designer du reste, mais, en général, on en abuse pas en dehors de ce cas.

Les classes partielles statiques, même si il n'y a pas d'objection technique, c'est déjà plus capillotracté; c'est une idée originale, disons.


La description de ton problème ressemble plus à un problème de design qu'à un problème de programmation.

[ced600]

Je suis un peu d'accord avec BlueDeep sur le problème potentielle de design.

Mais si tu veux vraiment le faire, comme smyley je ferais une ou plusieurs méthodes d'initialisation (appelée ou non dans la property à toi de voir)

pour moi un constructeur = méthode d'initialisation appelé à l'instanciation de la classe.

Donc quand je ne peut pas utiliser les constructeur ....

Ce qui est drôle c'est de voir dans les MS, les constructeurs de classes appelés des méthodes d'initialisation
(j'ai en tête le code généré automatiquement pour un winforms)

[Bluedeep]

Ce qui est drôle c'est de voir dans les MS, les constructeurs de classes appelés des méthodes d'initialisation
(j'ai en tête le code généré automatiquement pour un winforms)

Je ne vois pas ce que tu trouves de drôle/choquant à cela : quand tu as des constructeurs multiples, c'est parfaitement logique (et il est fréquent d'en ajouter sur les objets hérités de UserControl ou de Form).

[ced600]

Je ne vois pas ce que tu trouves de drôle/choquant à cela : quand tu as des constructeurs multiples, c'est parfaitement logique (et il est fréquent d'en ajouter sur les objets hérités de UserControl ou de Form).

J'ai utilisé un mauvais terme, je ne trouve pas cela choquant.
Je m'étais en évidence leur façon de faire que je trouve correcte.
Dans ma tête j'y opposais le comportement de certain à charger le constructeur avec 50 000 lignes de codes d'initialisations. Je suis plus pour l'appel à une ou plusieurs méthodes d'initialisations.

[Bluedeep]

J'ai utilisé un mauvais terme, je ne trouve pas cela choquant.
Je m'étais en évidence leur façon de faire que je trouve correcte.
Dans ma tête j'y opposais le comportement de certain à charger le constructeur avec 50 000 lignes de codes d'initialisations. Je suis plus pour l'appel à une ou plusieurs méthodes d'initialisations.

OKI Nous sommes donc sur la même longueur d'onde.

[maa]

Euh .... déjà, sans préjuger de la solution, la description du problème respire l'embrouille de première classe

Les classes partielles, ok, ça permet de ne pas mélanger le code généré par le designer du reste, mais, en général, on en abuse pas en dehors de ce cas.

Les classes partielles statiques, même si il n'y a pas d'objection technique, c'est déjà plus capillotracté; c'est une idée originale, disons.

Je ne pense pas dans mon cas.

Je parle de la classe Globals généré par VSTO. Elle contient la référence à ThisDocument (document office) à une collection de Ribbon (ruban office) c'est à dire à toutes les classes représentant une interface graphique de l'application. Il est logique d'y ajouter une collection de Form, les panneaux latéraux, etc.. je trouve. Bien sûr, je pourrais créer une nouvelle classe statique mais à quoi bon séparer dans deux classes des infos du même type ? Et qui plus est souvent interdépendantes.

J'avais comme ceci :

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
32
 
    internal sealed partial class Globals
    {
        public static Windows Windows
        {
            get { return Windows.GetInstance(); }
        }
 
        private HierarchyPane _HierarchyPane;
        public HierarchyPane HierarchyPane 
        {
            get 
            {
                if (_HierarchyPane == null)
                {
                    _HierarchyPane = new HierarchyPane(ThisDocument);
                    ThisDocument.ActionsPane.Controls.Add(_HierarchyPane);
                }
                return _HierarchyPane; 
            }
        }
    }
 
    public class Windows : Singleton<Windows>
    {
        private Windows() 
        {
            Login = new LoginWindow();
        }
 
        public LoginWindow Login { get; private set; }
    }

Je me demandais juste si il n'y avait pas une méthode plus simple pour centraliser l'initialisation des propriétés.

[ced600]

Juste une chose pour la classe statique : Tu n'aurais d'intérêt à la faire que si les méthodes de celle-ci sont indépendante de n'importe qu'elle classe et peuvent être appelé par n'importe qui.

Je crois que ce n'est aps le cas là, non ? Dans ce cas en effet la classe statique ne convient pas.

Ribbon (ruban office) c'est à dire à toutes les classes représentant une interface graphique de l'application. Il est logique d'y ajouter une collection de Form, les panneaux latéraux, etc..

Rien ne t'empêche de séparer cela en plusieurs classes.
Ce que je veux dire c'est que tu peux considérer ta classe globals comme un sous-système, que tu peux diviser en plusieurs sous-système.
Cela me paraît pas mal comme idée. Plus simple à maintenir, évoluer. Plus adaptable.

[maa]

Je crois que ce n'est aps le cas là, non ? Dans ce cas en effet la classe statique ne convient pas.

Si, elles doivent être utilisables depuis n'importe quelle form/ruban/panel de mon projets. C'est d'ailleurs bien pour cela que Microsoft à jugé utile de mettre ces infos dans cette classe statique. Je ne fait qu'enrichir cette classe avec des infos du même type. Je pourrais mettre mes infos dans une classe à moi, mais je séparerais dans 2 classes différentes des infos similaires. Je ne vois pas l'intérêt...

[ced600]

En fait je n'avais pas compris correctement ton problème.
Maintenant si et donc ce que tu fais me parait correcte