繼承的設計理念

我有兩個不相關的類繼承的設計理念

public class ManagedType{ 
    private string id; 
    private string name; 
    private string description; 
    private string version; 
    private string Properties; 
    private List<string> baseTypesl 
} 

public class OtherClass{ 
    private string id; 
    private string name; 
    private string description; 
    private string target; 
    private string sources; 
    private List<string> relationships; 
}

因此，它是建議，如果我抽象出來的ID，名稱，描述成一個新的基類，讓它擴展這一點。

我的看法是，因爲它們是不相關的，我們不應該。此外，我們絕不應該只爲屬性擴展類（除非它們是相關的），而只適用於普通行爲（這裏沒有）。請讓我知道你的看法。

來源

2017-05-31 Nishant

相依手段無關。繼承意味着'是'。如果你不能說人們認爲「其他」，你甚至不應該考慮繼承。 –

順便說一句，這不是關於設計模式。這是關於繼承和麪向對象原則的定義 –

https://stackoverflow.com/questions/49002/prefer-composition-over-inheritance – jaco0646

你以前可能聽說過這個：「繼承代表一種'是一種'關係'。

來決定是否使用繼承與否，簡單地問自己：

是ManagedType和OtherClass同樣的事情？

如果您的答案是「是」，請創建一個公共超類。

~~就這麼簡單。~~您還必須考慮是否在這裏使用繼承會使您的代碼以任何方式「更好」。我現在無法想象這樣的情況，但是如果你看到繼承是否存在並不會影響你的其他代碼片段，那麼繼承可能是不必要的。如果你使用繼承和思想「哦，現在繼承，我可以簡化我的代碼這樣！」，那麼它可能是好的在那裏。

此外，我們不應該只爲屬性（除非它們是相關的）擴展一個類，而只是爲了普通行爲（這裏沒有）。

我從來沒有聽說過這樣的事情。我認爲這取決於你所處的具體情況。

來源

2017-05-31 10:10:40 Sweeper

你的理解是正確的。除非他們不屬於'is-a'關係，否則將他們歸入一個超級階級是毫無意義的。

但是，這個'是'關係只有從功能角度來看纔會出現。如果你正在構建一個服務類，比如Serializable，IEnumerable等，你可能會認爲帶一個接口有3個屬性（我可以看到ID，名稱和描述）是常見的。僅當您從技術服務角度看到此情況時才適用。但是，如果你從功能角度來看，你不應該把抽象類。

例如，

public interface Iloggable 
{ 
    public string id {get; set;} public 
    string name {get; set;} 
    public string description {get; set;} 
} 

public class ManagedType: Iloggable 
{ 
    private string _id, _name,_description; 
    public string id 
    { 
     get 
      {return _id;} 
     set {_id = value; } 
    } 
    ..... 
}

來源

2017-05-31 11:11:01 Barani

繼承的設計理念

回答

相關問題