Propriétés get et set séparées dans deux interfaces.

Version imprimable

19/04/2013, 16h57
antoine.debyser

Propriétés get et set séparées dans deux interfaces.
Bonjour tous le monde,

Aujourd'hui je suis face à un cas de consience. Est-ce sale de casser l'heritage dans une interface dans le but de séparer le getter du setter ? :oops:

Peut etre qu'un bou de code sera plus parlant
Code:

1 2 3 4 5 6 7 8 9 public interface IPerson { string Name { get; } } internal interface IPersonWriteable : IPerson { new strnig Name { get; set; } }
C'est le fait d'être obliger de reprendre get, et d'utiliser new, qui m'a intrigué.

Mon besoin réel est légèrement différent du cas ci-dessus. Mais la question reste entière, est-ce sale? Ou est-ce une faiblesse du language/compilateur qui m'oblige à mettre "new" et reprendre le getter ?

Oui je sais, c'est une question délicate pour un vendredi après midi :mouarf:
19/04/2013, 17h29
Er3van

Selon moi, oui, tu casses l'héritage.

Logiquement si ton IPerson ne doit pas être "settable", alors quelque chose qui hérite de cette interface ne devrait pas l'être non plus.

Ne serait-ce pas plus logique d'avoir un set dans IPerson, et deux interfaces IPersonReadOnly (get uniquement) + IPersonWriteable (get + set) qui héritent de IPerson ?

Ou alors j'ai raté un truc... vendredi après-midi quand tu nous tiens ;)
19/04/2013, 17h54
antoine.debyser

Citation:

Envoyé par Er3van

Ne serait-ce pas plus logique d'avoir un set dans IPerson
...
Ou alors j'ai raté un truc... vendredi après-midi quand tu nous tiens ;)

Le fait que si tu met un set sur IPerson, il sera forcement public sur la classe qui implemente IPerson.

En gros, je ne veux pas exposer le setter à tous le monde. Pour clarifier un peu la situation, j'ai modifié l'exemple en rendant IPersonWriteable internal.

bonjour

Le new dans l'heritage de class ou interface signifie ajout d'une nouvelle methode en plus de l'existante avec meme nom et signature...
2 methodes vont exister dans l'interface et les appels au methodes doivent se faire via l'interface pour les distinguer...
Si tu demandes une implementation explicite tu seras eclaire sur le fonctionnement interne....et donc comment l'adapter au besoin....

Code:

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
 
 public interface IPerson
    {
        string Name { get; }
    }
 
    public interface IPersonWriteable :IPerson 
    {
      new   string Name { get; set; }
 
    }
 
    public class Person :IPersonWriteable 
    {
 
        private string n;
        string IPersonWriteable.Name
        {
            get
            {
                return n; 
            }
            set
            {
                n = value;
            }
        }
 
        string IPerson.Name
        {
            get { return n; }
        }

bon code..............

Je connais bien la définition de "new", je sais tres bien aussi utiliser l'implementation explicite d'une interface.

Ma question n'est peut être pas assez clair. Aller hop reformulation, et autre exemple.
Je cherche a savoir si mon premier exemple est valide d'un point de vue POO ?
Je cherche simplement a étendre un contrat. En C# un contrat est représenté par une interface. Comme j'utilise dans le cas présent des propriétés, je suis obligé de re-déclarer la propriété.
Du fait que je re-declare la propriété, suis-je réelement obligé de mettre "new" ? (Voir la fin du post pour un mystère de plus)
Le faire est-ce aller à l'encontre de la POO, ou est-ce C# qui empêche d'utiliser correctement une interface.

Pour aider à la réflexion qui m'habite un autre exemple :
Sans utiliser de propriété
Code:

1 2 3 4 5 6 7 8 9 public interface IPerson { string GetName(); } internal interface IPersonWriteable : IPerson { void SetName(string name); }
En ce passant de propriété il n'y a aucun problème.

Pire encore en faisant des test je me suis aperçus que le code suivant compile sans erreur, sans warning (même niveau 4), et fonctionne parfaitement.
Code:

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 public interface IPerson { string Name { get; } } public interface IPersonWritable : IPerson { string Name { get; set; } } public class Person : IPersonWritable { private string _name; public string Name { get { return _name; } set { _name = value; } } } public static void Test() { IPersonWritable p = new Person(); p.Name = "TOTO"; IPerson readOnlyPerson = p; Console.WriteLine("IPersonWritable.Name : {0}", p.Name); Console.WriteLine("IPerson.Name : {0}", readOnlyPerson.Name); }
A la vue de cet exemple, soit "new" est mal géré, soit C# a une implémentation plus logique des interfaces au niveau des propriétés, même si cela semble incorrect à la première lecture.
Ce qui me ramène à la nécessité réel ou non de l'utilisation de "new" dans ce cas?

rebonjour antoine.debyser

Je me suis peut etre mal explique ..
Cela veut dire foin de l'interface IPerson...
Car un class implementant IPerson (ou l'on ne peut pas setter prop Name) verrait sa prop sette facilement via un autre class PersonWritable implementant IPersonWritable :
comme le montre ce code:

Code:

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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace WindowsFormsApplication1
{
    public interface IPerson
    {
        string Name { get;  }
    }
 
    public interface IPersonWriteable :IPerson 
    {
      new   string Name { get; set; }
 
    }
    public class Person : IPerson
    {
 
 
        private string n = "IPerson";
 
        public string Name
        {
            get { return n; }
        }
    }
 
    public class PersonWritable:IPersonWriteable 
    {
 
 
        private string n = "IPersonWriteable ";
 
        public string Name
        {
            get
            {
                return n;
            }
            set
            {
                n=value;
            }
        }
    }
}

code .cs du test:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
private void button1_Click(object sender, EventArgs e)
        {
            IPerson person1 = new Person();
            textBox1.Text = person1.Name;
 
            IPersonWriteable person2 = new PersonWritable();
            person2.Name="malvenu";
            person1 = (IPerson)person2;
            textBox2.Text = person1.Name + " - " + person2.Name;
 
 
         }

C'est pour cela que j'ai attire ton attention sur l'ajout car un type implementant IPersonWritable peut etre caste en IPerson a cause de l'heritage d'interface...
Par contre l'inverse n'est pas possible et ne compile pas pour plus de surete.....
Maintenant tout depend du besoin....
bon code.....

20/04/2013, 12h22
ElTotor

Bonjour,

Citation:

Envoyé par MABROUKI

Car un class implementant IPerson (ou l'on ne peut pas setter prop Name) verrait sa prop sette facilement via un autre class PersonWritable implementant IPersonWritable :

Si j'ai bien compris, tu indiques que le nom d'une IPerson peut être modifié via le setter en passant par l'interface IPersonWriteable.

C'est uniquement vraie si l'instance contenue dans une variable de type IPerson est une instance d'une classe implémentant IPersonWriteable.

Dans ton exemple, tu essaies de montrer que le nom de person1 est modifié. Ce n'est pas vrai. Ce n'est pas le nom qui est modifié, mais l'instance référencée par person1 à la ligne 9.

Il n'est pas possible de modifier le nom de l'instance créée via new Person()
22/04/2013, 10h32
ClaudeBg

Salut
------

Bon, je fais peut-être erreur, mais selon moi il n'y a aucun problème dans ce qui est expliqué et c'est une mauvaise interprétation des interfaces et des héritages qui explique ce qui semble être une anomalie.

Une interface, c'est un contrat. Hériter une interface d'une autre interface, c'est hériter un contrat d'un contrat. Dans le cas en question, ça ne veut en aucun cas dire qu'une classe implémentant l'interface IPersonWritable est une classe qui hérite d'une autre implémentant IPerson. Il n'y a donc ici aucun défaut au niveau de l'héritage, on ne casse rien.

Pour être plus explicite :

Si classe1 implémente l'interface IPerson, ça veut dire qu'elle doit fournir au minimum un accesseur "get" pour la propriété "Name".

Ça ne veut en aucun cas dire que "Name" ne dispose pas d'un accesseur "Set", ça veut juste dire que ce n'est pas imposé par le contrat.

Dit autrement, mettre uniquement l'accesseur "Get" pour la propriété "Name" ne veut en aucun cas dire que "Name" est en lecture seule, le contrat n'impose pas l'absence de "Set" mais bien la présence de "Get".

Partant de là, si on dérive l'interface, ça revient simplement à ajouter des clauses au contrat. Ainsi, dans ce cas, on ajoute l'obligation de l'accesseur "Set".

Est-ce que ça casse l'héritage? Ben non, il n'y a aucune notion d'héritage au niveau des classes, et au niveau des contrats le contrat IPersonWritable respecte bien l'héritage, puisque le contrat IPerson dit "on impose l'accesseur Get" et IPersonWritable dit "Et en plus on impose l'accesseur Set".

Bref, si on a l'illusion que la classe implémentant IPerson a une propriété "Name" en lecture seule, ce n'est vrai QUE si on fournit une référence de la classe en tant que contrat IPerson, et donc ça ne donne simplement pas à l'utilisateur la possibilité d'utiliser "set" puisque sa présence n'est pas garantie. La classe, elle, peut fort bien disposer d'un "Set" sur "Name", c'est juste qu'au niveau du contrat on ne le voit pas.

Or, une classe qui propose l'accesseur "Set" + "Get" (donc IPersonWritable) propose bien de fait l'accesseur "Get" (donc IPerson), et donc tout est respecté et il n'y a aucun bris de l'héritage nulle part.

Citation:

Logiquement si ton IPerson ne doit pas être "settable"

Toute la confusion (selon moi) est résumée par cette phrase: Le contrat IPerson ne dit en aucun cas que "Name" ne doit pas être "settable", il dit juste qu'il doit être "Gettable" (si j'ose dire).

C'est comme avec tout contrat de la vie réelle. Si L'Europe impose un contrat de vente avec au moins 2 ans de garantie et qu'un constructeur décide d'hériter de ce contrat en augmentant la garantie à 5 ans, il respecte bien le contrat dont il hérite, il n'y a aucun défaut d'héritage.

Citation:

En gros, je ne veux pas exposer le setter à tous le monde

Tu fournis une référence à ta classe castée en IPerson, et pour ceux qui ont accès au "set", tu fournis ta classe castée en IPersonWritable. C'est exactement le rôle des contrats, donc tu ne commets à mon avis aucune "infraction" aux notions d'héritage et d'objet. Le constructeur dans mon exemple ci-dessus peut fort bien fournir le contrat de garantie de 2 ans pour un pays et celui de 5 ans pour un autre pays, concernant le même produit, et sans remettre en cause la législation.

A+
Claude
23/04/2013, 14h42
Guulh

Plusieurs remarques.

Déjà, comme le dit Claude, il n'y a rien de choquant à ce qu'une classe ait une propriété get set alors que l'interface ne mentionne que le get.

Ensuite, as-tu besoin de IPersonWritable ? Auras-tu plusieurs classes qui vont l'implémenter ? Veux tu masquer l'implémentation de Person à des modules qui pourraient éventuellement manipuler des IPersonWritable ?

Person est-il un bête DTO ? Dans ce cas, je serais plus que dubitatif sur l'emploi d'interfaces. Si au final ta classe Person n'implémente IPerson que via un bête get/set, tu ne gagnes rien à la planquer derrière une interface. Les classes non-DTO, c'est évidemment une autre histoire.
24/04/2013, 14h47
antoine.debyser

Bonjour,

merci pour vos réponses, j'ai moi même fait quelques avancées sur le sujet.

Déjà, je vois que je suis arrivé à la même conclusion que ClaudeBg, mais sa formulation est tellement plus clair que la mienne.

Ensuite, petit raté dans mes tests, le cas évoquer dans mon 3ieme post, compile avec un Warning (le fait qu'il n'y ai pas de new).

Enfin pour Guulh, mon cas réel n'est pas aussi trivial, Il s'agit de mettre en commun deux interfaces qui n'ont rien avoir fonctionnellement entre elles, mais qui présentent des objets ayant les mêmes caractéristiques. Pourquoi mettre en commun, pour mutualiser la logique d'affichage.
Sinon dans un cas plus proche de l'exemple, il est clair que cette séparation n'a d’intérêt que dans une logique métier. Certain peuvent écrire, d'autre non.

Du coup, je pense que je vais marquer le sujet comme résolu.
Avec la conclusion suivante, "non c'est n'est pas sale"
24/04/2013, 15h10
g.Arnaud

Citation:

Envoyé par antoine.debyser

Enfin pour Guulh, mon cas réel n'est pas aussi trivial, Il s'agit de mettre en commun deux interfaces qui n'ont rien avoir fonctionnellement entre elles, mais qui présentent des objets ayant les mêmes caractéristiques. Pourquoi mettre en commun, pour mutualiser la logique d'affichage.

Pourquoi ne pas faire une troisième interface pour les caractéristiques communes dont tu aura besoin pour l'affichage?