2009-09-06 5 views
4

Je voudrais avoir plusieurs versions d'un objet avec des modificateurs d'accès différents sur les propriétésC# Modificateurs d'accès avec l'héritage

Par exemple, je pourrais avoir un utilisateur classe-

public abstract class UserInfo 
{ 
    internal UserInfo() 
    { 
    } 
    public virtual int ID { get; set; } 
    public virtual string Password { internal get; set; } 
    public virtual string Username { get; set; } 
} 

public class ReadUserInfo : UserInfo 
{ 
    internal ReadUserInfo() 
    { 
    } 
    override public int ID { get; internal set; } 
    override internal string Password { get; set; } 
    override public string Username { get; internal set; } 
} 

public class NewUserInfo : UserInfo 
{ 
    internal NewUserInfo() 
    { 
     ID = -1; 
    } 
    //You get the Idea 
} 

Est-ce quelque chose que je peut mettre en œuvre ou dois-je contrôler l'accès d'une manière plus programmatique?

+1

Je dois mentionner que le code ci-dessus donne un « Impossible de modifier les modificateurs d'accès lors de la substitution « pubienne » hérité membre ... Erreur –

+0

Qu'est-ce que vous –

+2

Je suis d'accord avec Nader: déclarer une propriété publique dans une classe de base, puis la cacher dans une classe dérivée est juste Je chercherais une nouvelle approche du problème, peut-être qu'une interface implémentée par certaines classes et pas par d'autres résoudra votre problème – ScottS

Répondre

4

vous pouvez utiliser le nouveau modificateur:

public class ReadUserInfo : UserInfo 
{ 
    internal ReadUserInfo() 
    { 
    } 
    new public int ID { get; internal set; } 
    new internal string Password { get; set; } 
    new public string Username { get; internal set; } 
} 
+0

J'ai testé cela, et cela ne fonctionne pas du tout. La propriété "Password" de la classe de base est toujours visible dans l'autre assembly. –

+0

Lorsque vous héritez d'une base, vous créez une nouvelle classe, vous ne modifiez pas le comportement de la classe de base. Bien sûr, la propriété 'Password' de UserInfo est toujours visible en dehors de l'assembly mais ReadUserInfo.Password ne l'est pas. – manji

+0

@najmeddine: À droite, ce qui signifie que si vous le transtypez correctement (ou incorrectement) dans l'assemblage, vous obtiendrez soit UserInfo.Password, soit ReadUserInfo.Password. Cela fait partie du problème avec cette approche. –

14

Est-ce l'héritage vraiment bon ici? Les utilisateurs de la classe UserInfo ne devraient pas avoir besoin de connaître les sous-types. Dans ce cas, les utilisateurs doivent savoir que la propriété Password est en quelque sorte indisponible lorsque l'instance ReadUserInfo est attribuée au lieu d'une instance UserInfo.

Cela n'a vraiment aucun sens.

Edit:. Dans la conception orientée objet, cela est connu sous le nom Liskov Substitution Principle

+0

C'était la moitié d'une réécriture expérimentale, la moitié d'un exercice d'apprentissage sur un projet personnel. Je ne savais pas si j'allais dans la bonne direction. Je me suis également trompé de comportement quand je l'ai stocké dans le type de base. Alors ouais c'était une mauvaise idée. Merci pour la contribution! –

Questions connexes