Discussion :

[dahtah]

Bonjour à tous,
Comment accède-t-on à l'instance de la classe mère.
Par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public class Animal
{
    notifierChangement(Object unObjet) {}
}
 
public class Chien : Animal {}
public class Chat : Animal {}
 
public static void Main() 
{
    Animal a = new Animal();
}

Comment puis-je accèder dans le corps de Chien et Chat à l'instance de Animal? Je voudrais que la méthode notifierChangement soit accessible à Chien et Chat via l'instance a (Donc pas par le mot clé base).
Si quelqu'un a une idée...
Je sens que c'est encore une erreur de conception...

[Mehdi Feki]

Tu la marque protected.

Niveaux d'accessibilité (Référence C#)

[dahtah]

J'y avais pensé, mais ça me force à instancier la classe où se trouve l'instance de la classe Animal.
C'est pas très pratique. Il n'y a pas un autre moyen (mis à part static)? Par réflexion par exemple?
Merci...

[The_badger_man]

Je sens que c'est encore une erreur de conception...

J'en ai l'impression, mais j'avoue n'avoir rien compris à ta demande. Essaye un autre exemple, avec d'autres explications (sur ton pb mais aussi sur ton but final, car il y a surement une autre façon d'y arriver).

[SirJulio]

J'y avais pensé, mais ça me force à instancier la classe où se trouve l'instance de la classe Animal.
C'est pas très pratique. Il n'y a pas un autre moyen (mis à part static)? Par réflexion par exemple?
Merci...

Salut,

ton propos n'est pas tres clair, mais si ta methode est protégée, tu peux y acceder depuis toute ta hierarchie de derivées, pas besoin d'instancier un autre objet puisqu'un chien est intrinsequement un animal, donc dans une methode de chien, tu peux sans probleme utiliser une methode protected d'une ou de la classe de base.

[hed62]

de plus, "base" te renvoie bien une instance d'Animal (en exagérant, cela te renvoie ton Chien casté en Animal)

[dahtah]

Merci de vos réponse.
Dans chacune de mes classes dérivées, j'aimerai pouvoir faire

Code :

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

a.notifierChangement();

a étant l'instance de la classe mère animal. a étant instancié dans un autre package.
Je vais essayer d'expliquer ce que je veux faire. Dans mon point d'entrée de mon programme, je crée une instance de la classe Animal.

Point d'entrée :

Code :

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

Animal a = new Animal();

C'est mon poit d'entrée de la couche model. Cette classe est passée en paramètre au constructeur du controlleur de Animal.

Controlleur :

Code :

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

ControlleurAnimal c = new ControlleurAnimal(a);

a peut donc enregistrer des vues à notifier dans le controlleur.

Code :

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

a.register(IAbstractVue vue);

.
Jusque là nickel.

Modèle :
Mais la classe Animal possède des classes dérivées dans la couche modèle. Dans ces classes dérivées je souhaiterai faire par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
public class Chien
{
    private String manger;
 
    public String Manger {
        set { return manger; }
        get { manger = value;
                a.notifyChange(new mangerChangedEvent(manger));
        }
}

Je dois donc accèder à l'instance de a pour annoncer les changements du modèle à la vue (Pattern Observer).
Voili, voilou...
Merci...

[SirJulio]

Salut,

mais je ne comprends pas trop le role de Chien la dedans. a est un Animal (du moins dans ton explication est instancié comme tel), pas un chien, donc si tu veux appeller a depuis Chien, on ne parle plus de derivée mais de deux instances differentes, et tu doit le passer en constructeur (ou en property) pour avoir une reference dessus.

Bref a quel moment est ce que tu instancies un Chien dans ton programme ?

[Skyounet]

Je rejoins SirJulio, il est clair que dans ton exemple Animal et Chien sont 2 classes complètements distinctes.

Dans ton exemple tu cherches juste à récupérer ton instance de Animal à partir de n'importe quelle autre classe.

Peut-être un membre static peut te convenir.

[dahtah]

Merci de vos réponses,
L'héritage de la classe Animal par Chien et Chat n'est effectivement pas obligatoire, je pourrai accèder à l'instance de Animal par une méthode static.
En fait, Chien et Chat, son créé par una autre vue et un autre controleur. Dans l'appli, il y a deux parties : le dessin, qui crée des objets, et l'affichage des données des objets crées. Chien et Chat son crée dynamiquement en fonction du dessin.
Je pensai que si chaque Chien et Chat héritai directement de Animal, leur affichage serai plus simple.
Une proriété static semble être la solution, celle que je voulais éviter. Ca force ma classe modèle à récupérer l'instance de Animal dans le main du programme, ou dans le controlleur. Pas terrible.
Merci à tous. Si y'a pas d'autres idées, je le tag comme résolu.

[hed62]

Mais pourquoi tu n'utilise pas l'héritage ?...

Chien hérite de Animal. Chat hérite de Animal aussi.

Code :

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

1
2
3
4
5
public String Manger {
        set { return manger; }
        get { manger = value;
                base.notifyChange(new mangerChangedEvent(manger));
        }

Ca marchera sans aucun problème !

Mais peut etre que tu ne veux qu'une seule instance de Animal ? Si c'est vraiment observer/Observed que tu veux implémenter, tu t'y prend mal !

Animal reste une classe mere de Chien et Chat. Il te faut une classe Observer, et une operation Animal.registrer(Observer) et une List<Observer> pour les observer enregistrés.
Puis, Animal possède une opération sendToObservers qui effectuera un foreach sur chaque observer pour les avertir.
Ensuite, dans Chien.Manger, tu declenchera base.sendToObservers


Ca, c'est le patron Observer/Observed.

En tous cas, il te faut revoir ton nommage de classes, et meme surement la conception !

[dahtah]

Le nom des classes, ce sont des exemples...
Ma classe Animal est en fait une classe ObervableImplementation, qui implémente une interface IObservable. Ma classe ObservableImplementation possède tout ce que tu cites. Mes vues implémentent l'interface IObserver.

Animal reste une classe mere de Chien et Chat. Il te faut une classe Observer, et une operation Animal.registrer(Observer) et une List<Observer> pour les observer enregistrés.
Puis, Animal possède une opération sendToObservers qui effectuera un foreach sur chaque observer pour les avertir.
Ensuite, dans Chien.Manger, tu declenchera base.sendToObservers

Le problème, c'est que mes objets sont crées dynamiquement (je ne connais ni leur nombre, ni leur type au départ). Je ne peux donc pas les passer au controleur, comme dans le Pattern Observer classique.

Code :

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

1
2
3
4
5
public String Manger {
        set { return manger; }
        get { manger = value;
                base.notifyChange(new mangerChangedEvent(manger));
        }

Le but étant de centraliser les évènements, en déclenchant les évènements sur une classe générale, qui elle est passée au constructeur du controleur. Je souhaite donc n'avoir qu'une classe ObserverImplementation (ou Animal pour hed62, ). Si j'utilise base, ça veut dire que mon controlleur est conscient de l'instance Chien, ce qu'il n'est pas.
Merci à tous de votre aide en tout cas...

[hed62]

oula.. repartons sur de bonnes bases... juste une note : les design pattern ont plusieurs objectifs, dont l'un d'eux est de fournir un vocabulaire commun. Parler d'un design pattern sans dire que s'en est un, et tenter de l'expliquer par de l'héritage alors qu'il n'y en a pas est le meilleur moyen de tout mélanger dans la tete des gens

Donc on reprend :

ObervableImplementation --|> IObservable
View --|> IObserver
selon le pattern du meme nom.

Le problème, c'est que mes objets sont crées dynamiquement (je ne connais ni leur nombre, ni leur type au départ).

Cela n'est pas genant en soi... Puisque ton Obervable gère une liste d'observed, qui possèdent tous la meme interface, il est en mesure de les gérer tous, quel que soit leur nombre.

Le but étant de centraliser les évènements, en déclenchant les évènements sur une classe générale

La, tu déroges au pattern : selon le pattern, tu a 1 Observable ---> N Observer qui s'adaptent et sont notifiés.
Si tu veux centraliser tout en restant conforme au pattern, intercale une classe entre IObserver et tes sous-types de View : une classe générale qui fait le traitement.

Si tu as besoin de spécialiser le traitement selon le sous type de vue, regarde le design pattern Patron de Methode.

[dahtah]

En tout cas Hed62, merci beaucoup de ton aide.
Ok, alors j'ai :

Code :

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

1
2
3
4
5
6
 
public interface IObservable
{
    void register(IObserver unOberver);
    void unregister(IObserver unObserver);
}

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
 
public class ObservableImplementation : IObservable
{
    private List<IObserver> container;
 
    public void register(IObserver anObserver) {
        container.Add(IObserver anObserver);
    }
 
    public void unregister(IObserver anObserver) {
        container.Remove(IObserver anObserver);
    }
 
    public void notifyObservers(Object anObject) {
        foreach (IObserver anObserver in container) {
            anObserver.notify(anObject);
        }
    }

Code :

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

1
2
3
4
5
 
public interface IObserver
{
    void notify(Object unObjet);
}

Normallement dans le pattern Observer, chaque classe Observable hérite de la classe ObservableImplementation. Les vues IObserver sont notifiés.
Ca y est, je vois où je me suis mal exprimé. Dans mon cas, j'ai plusieurs vues IObserver affichant les données des classes héritant de ObservableImplementation (objet Chien par exemple). 1Observable ---> N Vues. Jusque là tout est normal.
Mon vrai problème, c'est que plusieurs objets Chien ont la même vue. Soit une association N Observable ---> 1 Vue. Tout dépend sur quel objet Chien l'utilisateur clique. Quand on clique sur un objet Chien, la fenetre chien s'ouvre et les données propres à l'objet cliqué sont mises à jour.
Au moins, mon problème s'éclaircit. Existe-t-il un tel Pattern?

Si tu veux centraliser tout en restant conforme au pattern, intercale une classe entre IObserver et tes sous-types de View : une classe générale qui fait le traitement.

Si tu as besoin de spécialiser le traitement selon le sous type de vue, regarde le design pattern Patron de Methode.

Ca c'était mon idée de départ.
Pour rester fidèle au Pattern, il faut que je résolve différement ce problème N Observable ---> 1 Observer.
Merci encore hed62.

[hed62]

N Observable --> 1 Observer est possible, en découplant ainsi (si pas trop de Observable) :

3 Interface IObservable et 3 Interfaces IObserver
les N Observables =
a ---|> IObservable1
b ---|> IObservable2
c ---|> IObservable3
le Observer =
Vue ---|> IObserver1,IObserver2,IObserver3

a register ((IObserver1)Vue)
b register ((IObserver2)Vue)
c register ((IObserver3)Vue)

Et ainsi, chaque appel notify 'tombe' dans une méthode différente de la Vue. Cela n'est correct que si le nombre de IObservable est clairement défini et fixe (oui, cela arrive parfois )

Si non :
Revien sur du N-->1 en ajoutant une sur-interface IObservableBase qui a une méthode getType() qui te permettra de faire un switch afin de connaitre quelle branche employer.

[dahtah]

J'avais pensé à un truc du genre de la première solution, mais comme tu l'as dit :

Cela n'est correct que si le nombre de IObservable est clairement défini et fixe (oui, cela arrive parfois )

La deuxième solution est pas possible non plus, car tous les objets représenté dans la même vue sont de même types.
Enfin bon ,merci beaucoup de ton aide.
Je vais supprimer l'héritage et opter pour la solution du getter/setter static dans le controlleur. Chaque vue recevra tous les notify() et fera un test du type d'event la concernant (si event est du type mangerChangedEvent, alors je suis concerné).
Un grand merci à tout le monde, et surtout à hed62.