Discussion :

[azstar]

bonjour

Je cherche une méthode pour masquer une propriété dans une classe parent via une classe fille.

Code :

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

1
2
3
4
5
6
7
 
 
public class parent 
{
public XmlDocument xmlcontent {get;set;}
public int Id {get;set;}
}

avac une classe fille pour faire

Code :

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

1
2
3
4
5
6
 
 
public class fille:parent
{
///quelque chose pour masquer ça public XmlDocument xmlcontent {get;set;}
}

J'aurai que id qui est public dans ma classe fille.

NB: la classe parent est auto-générée donc il faut la toucher

merci d'avance

[theMonz31]

ce que tu demandes, c'est en total opposition avec les principes de la programmation objet...

[alavoler]

J'ai pas tout compris et je pense que theMonz31 à de bon conseil

Sinon rapidement pour masquer le polymorphisme avec le mot clé new (ce n'est pas ce que tu souhaites faire je crois mais bon...):
virtual dans la classe mère
override dans la classe fille // ça c'est le polymorphisme classique
new dans la classe fille // pour masquer le polymorphisme, et créer une nouvelle méthode/propriété

Ca sert typiquement pour gérer du versionning // enfin c'est surtout dans des cas critiques, généralement on a pas besoin d'un tel comportement

[azstar]

je sais

l'origine de mon problème est que ma classe parent est auto-générée et contient un XmlDocument, qui est indésirable dans mes traitements (sérialisation).

Je dois créer une autre classe fille qui hérite de cette classe (c'est parce que la classe est auto-générée ) pour avoir que les autres proprieties de telle sort que je sérialise que les autres

[alavoler]

https://msdn.microsoft.com/fr-fr/lib...vs.110%29.aspx
XmlIgnoreAttribut / [Nonserialized]

mais faut toucher à la génération de la classe mère... je ne sais pas si y a une astuce pour injecter cet attribut depuis la fille...

Sinon faut gérer soit même la sérialisation dans la classe fille, c'est peut être la meilleurs méthode pour ton problème.

EDIT: http://stackoverflow.com/questions/5...alizing-object

I don't think XML serialization can help you with what you're trying to do, unless you implement IXmlSerializable yourself...

NB: remarquez que le post contient une réponse de notre Thomas Levesque héhé

[pascalCH]

Bien que ce soit effectivement en totale opposition aux règles du modèle objet :

Code :

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

1
2
3
4
5
6
    public class fille : parent
    {
        ///quelque chose pour masquer ça public XmlDocument xmlcontent {get;set;}
        [System.Xml.Serialization.XmlIgnore]
        protected new XmlDocument xmlcontent { get { return base.xmlcontent; } set { base.xmlcontent = value; } }
    }

Entorse acceptée vu que la classe de base est auto-générée, mais n'y a t-il pas moyen d'intervenir sur le générateur de code ? et d'ailleurs, quel est -il ?

[alavoler]

A noter qu'avec la solution de pascalCH, tu rencontrera toujours ton problème si ton appel se fait ainsi:

Code :

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

parent o = new fille();

en effet, le xmlcontent sera celui du parent // contrairement au polymorphisme classique...
Donc tu risques de te retrouver à nouveau avec ton problème de sérialisation dans ce cas de figure
(j’espère ne pas dire de bêtise)

Sinon pour l'injection d'attribut, tu as peut être cette solution élégante:
http://stackoverflow.com/questions/2...nherited-class
https://msdn.microsoft.com/en-us/lib...attribute.aspx
// je compte sur toi pour nous en faire un feedback
EDIT: arf ca va pas marcher si ta classe générée n'est pas partielle... TOUJOURS mettre les classes générées en partial... ça sert à ça se mot clé justement

[pascalCH]

Code :

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

parent o = new fille();

en effet, le xmlcontent sera celui du parent // contrairement au polymorphisme classique...
Donc tu risques de te retrouver à nouveau avec ton problème de sérialisation dans ce cas de figure

Exact, pire encore,

Code :

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

fille f = new fille();

propose un xmlcontent publique (celui de parent !!)

du coup, un pattern dérivé de Façade permet de contourner le problème

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 parent
    {
        public XmlDocument xmlcontent { get; set; }
        public int Id { get; set; }
    }    
 
    public class fille 
    {
        internal parent _Parent = new parent();
 
        public int Id { get { return _Parent.Id; } set { _Parent.Id = value; } }
        // ... idem pour les autres propriétés de parent à récupérer
    }

[theMonz31]

je ne vois pas l'intérêt de masquer une propriété...

car, si c'est pour la "cacher" à des utilisateurs, avec la reflexion, on pourra toujours l'atteindre.

J'ai déjà vu du code pour contourner certaines limites imposées par Microsoft sur certaines classes et l'astuce consiste à modifier un membre privé...

Donc, vu que par reflexion, on peut tout faire.. pourquoi se faire chier à cacher les choses... franchement, ça va à l'encontre de la POO et de plus, c'est réel
intérêt... voir limitatif pour le futur...

On se pleins toujours d'avoir des restrictions.. alors pourquoi en mettre

surtout sur du code desassemblable

[alavoler]

theMonz31
Son problème vient de la sérialisation. Il ne l'a pas dit dans son premier message. Mais je ne pense pas que l'auteur veuille limiter quoi que ce soit
Ton avertissement a été claire et pertinent. Même si sa demande est étrange, j'ai appris des trucs !

HS: Si tu as le temps de répondre à mon thread sur le debug (même s'il n'est pas des plus limpide), je suis preneur. Je sais que tu as de la bouteille !
bon week à tous

[Invité]

Bonjour,
En complément de tout ce qui a été dit, il y a aussi un moyen de faire en sorte qu'une propriété ou une méthode publique ne puisse pas être proposé en IntelliSense, c'est une technique très souvent utilisée dans les classes de Microsoft : au dessus de ton membre, il suffit de mettre l'attribut EditorBrowsable avec le paramètre EditorBrowsableState.Never.

Attention : cela ne fonctionnera uniquement que si ta classe dérivée se trouve dans une bibliothèque de classe qui n'appartient pas à des projets de la solution, autrement dit, il te faudra faire une bibliothèque de classe, puis que tu la compiles et que tu références depuis ton projet principal la DLL générée. Pour faire simple, avec clic droit ajouter référence, si tu ajoutes l'assemblage avec "Parcourir" les membres avec l'attribut "EditorBrowsable(EditorBrowsableState.Never)" seront bien masqués mais si tu faire clic droit ajouter référence puis solution => projet, ces mêmes membres ne seront pas masqués.

Cela dit, j'ai bien précisé qu'ils étaient masqués dans IntelliSense, mais si on les tape en entier on y a quand même accès.

Concrètement, pour ton cas, cela va donner quelque-chose comme cela :

Code :

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

1
2
3
4
5
6
 
public class fille:parent
{
    [EditorBrowsable(EditorBrowsableState.Never)]
    public new XmlDocument xmlcontent {get;set;}
}

Un exemple concret : dans la classe CheckedListBox, la propriété DataSource est bien référencée parmi les propriétés existantes, mais si tu fais cela :

Code :

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

1
2
3
 
System.Windows.Forms.CheckedListBox toto = new System.Windows.Forms.CheckedListBox();
toto.DataSource = "";

Tu constateras qu'IntelliSense ne va pas jamais te proposer "DataSource". Si tu vas sur "Atteindre la définition", tu constateras que le membre "DataSource" a bien l'attribut "EditorBrowsable(EditorBrowsableState.Never)".

[azstar]

bonjour,

Le problème est dans la sérialisation des xml documents qui sont pas bon à utiliser dans une orchestration biztalk, et ma classe est utilisée par tout
donc je ne dois pas toucher.

et la sérialisation se fait par tout avec une méthode dont je dois pas toucher

voila toutes mes contraintes

[alavoler]

azstar
On t'as donné 3/4 solutions possibles... pour chacune, peux tu nous dire en quoi elles ne conviennent pas ?

Ph_Gr
Ah !! J'ai enfin compris pourquoi sur certain composants je n'avais pas la complétion... même si je ne comprend pas bien pourquoi MS a fait ce choix, car le binding marche quand même bien...
Bon par contre ça ne va pas l'aider car ça ne va pas empêcher la sérialisation de se déclencher.

[azstar]

azstar
On t'as donné 3/4 solutions possibles... pour chacune, peux tu nous dire en quoi elles ne conviennent pas ?

Ph_Gr
Ah !! J'ai enfin compris pourquoi sur certain composants je n'avais pas la complétion... même si je ne comprend pas bien pourquoi MS a fait ce choix, car le binding marche quand même bien...
Bon par contre ça ne va pas l'aider car ça ne va pas empêcher la sérialisation de se déclencher.

voila pourquoi :

1- modifier dans ma classse parent : ces solutions sont rejetées ,car ma classe est auto-générée c'est trop dangereux de faire des modifications dedans.
2- modifier la sérialisation : on utilise une méthode dans une DLL qui tout le monde l'utilise pour faire la sérialisation, donc pas question de customiser mon sérialisation.
3- utiliser l’attribut [EditorBrowsable(EditorBrowsableState.Never)] : je ne compte pas masquer une Propriété depuis intelligence mais la masquer pour ne pas la sérialiser.

[alavoler]

azstar euh.... en gros tu veux ne rien modifier tout en ayant un comportement différent... ça va être difficile, va falloir faire un choix (et un petit effort)

Peux tu nous expliquer, par exemple, En quoi est ce dangereux dans votre projet de mettre partial sur une classe générée ? (en sachant que c'est la bonne pratique pour les classes générées)

La solution de facade proposée par Pascal est aussi envisageable et correspond à la maitrise de votre sérialisation... meme question, Quel est l'impact critique sur votre projet ?

même question sur le masquage du polymorphisme, avec le mot clé new...

[azstar]

azstar euh.... en gros tu veux ne rien modifier tout en ayant un comportement différent... ça va être difficile, va falloir faire un choix (et un petit effort)

Peux tu nous expliquer, par exemple, En quoi est ce dangereux dans votre projet de mettre partial sur une classe générée ? (en sachant que c'est la bonne pratique pour les classes générés)

partial : signifier que ma définition de la classe est dans deux fichiers. donc y' a pas de valeur ajoutée de "partial"; sauf que je ne touche pas au contenu de ma classe générée.

[je sais que ce forum est dédié a c# ]

mon problème vient de biztalk ,dans une orchestration de transaction Long je ne peux pas utiliser des classes qui contiennent des types non sérialisables; pour ce là je me suis lancé dans cette piste.{je pense que c'est une fausse piste}.

maintenant; je suis sur une autre piste qui est 100% biztalk : j'utilise un scoop de transaction ATOMIC dans mon orchestration (de transaction LONG) et je déplace mon variable (qui contient des types non sérialisables) et du coup j'aurai pas d'erreur de serialisation.