C＃訪問修飾符與傳承

比如我可能有講座

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 
}

用戶具有不同的訪問修飾符對象的多個版本，這是我的東西可以實施還是必須以更加程序化的方式控制訪問？

來源

2009-09-06 Kelly Gendron

我要指出，當覆蓋在「無法更改訪問修飾符上述結果的代碼‘陰毛’繼承成員......錯誤 – 2009-09-06 21:43:43

你是什麼試圖實現？你在尋找設計幫助，還是隻是好奇這個方案是否會起作用？ – 2009-09-06 22:26:33

我必須同意Nader。在基類中聲明一個屬性public，然後將它隱藏在派生類中我會尋找一個新的方法來解決這個問題，也許一個接口是由一些類而不是其他人來解決你的問題 – ScottS 2009-09-06 22:30:20

您可以使用新修改器：

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; } 
}

來源

2009-09-06 21:48:57 manji

我測試過了，它實際上根本不起作用。基類中的「Password」屬性在其他程序集中仍然可見。 – 2009-09-07 05:40:33

當你從一個基地繼承你正在創建一個新的類時，你不會修改基類的行爲。當然，UserInfo的'Password'屬性在程序集外部仍然可見，但ReadUserInfo.Password不是。 – manji 2009-09-07 08:30:18

@najmeddine：正確，這意味着如果您在程序集中正確（或錯誤地）投射它，您將得到UserInfo.Password或ReadUserInfo.Password。這是這種方法的一部分問題。 – 2009-09-08 03:51:19

是繼承真的在這裏合適不合適？ UserInfo類的用戶不需要知道這些子類型。在這種情況下，用戶需要知道在給定ReadUserInfo實例而不是UserInfo實例時，Password屬性在某種程度上不可用。

這真的沒有意義。

編輯：在面向對象的設計，這就是所謂的Liskov Substitution Principle

來源

2009-09-06 22:22:37

這是半個實驗性重寫，半個人學習項目。我不確定我是否正朝着正確的方向前進。存儲回基本類型時，我的行爲也被誤認爲是錯誤的。所以，這是一個壞主意。感謝您的輸入！ – 2009-09-07 00:19:20

C＃訪問修飾符與傳承

回答

相關問題