只處理屬性時的界面與抽象類

-2

這不是一個技術性的障礙或挑戰，我會說這是一個一般的討論！如果這是一個不合適的論壇，請讓我知道我將刪除它..只處理屬性時的界面與抽象類

我有一個場景，在從web服務獲得10 xml，每個XML幾個常見的屬性和一些特定的屬性，該XML。

類結構看起來類似下面

Public abstract class employee 
{ 
    Public int Id {get; set;} 
    Public int Name {get; set;} 
} 

Public class PermanentEmployee: Employee 
{ 
     // PermanentEmployee specific props 
} 

Public class ContractEmployee 
{ 
     //Contractor specific properties 
}

鑑於上述情況，應Employee類是抽象的，或者它應該是接口。哪個更好。

我將只有屬性，沒有方法。

我的觀點：我會去的抽象類，因爲我可以重複使用性能，接口將沒有意義，因爲沒有方法..

來源

2017-04-10 Manthan Davda

作爲http://stackoverflow.com/help/dont-ask提到的 - '如果你的問這個問題的動機是：「我想參加一個關於______的討論」，那麼你不應該在這裏問。「 – Smartis

它仍然主要吸引選擇的答案，應該被關閉。 – Smartis

我認爲這個問題可以在[http://softwareengineering.stackexchange.com/questions](http://softwareengineering.stackexchange.com/questions）上提出 - 但只有在你提出了一些你需要的特定場景的情況下決定界面與抽象類 – Fabio

我要「重用」的屬性分爲若干個「子類」，我會一直使用抽象類。

如果你想只定義方法簽名而不是它的「邏輯體」，那麼使用接口。

總之，您與我們分享的源代碼，這將是我的方式。

來源

2017-04-10 07:53:27 Dryadwoods

我會定義一個接口IEmployee和抽象類。這給了一個接口的靈活性，以通用的方式傳遞，但抽象類對於那些否則必須重複代碼（乾等）的情況會很有用。

public interface IEmployee 
{ 
    int Id { get; set;} 
    int Name { get; set;} 
} 

public abstract class Employee : IEmployee 
{ 
    public int Id { get; set;} 
    public int Name { get; set;} 
} 

public class PermanentEmployee: Employee 
{ 
    // PermanentEmployee specific props 
} 

public class ContractEmployee : Employee 
{ 
    //Contractor specific properties 
}

來源

2017-04-10 08:00:35 Neil

抽象類也可以一般地傳遞，所以根據你的理由沒有需要界面。除了接口是語言中抽象類的「解決方法」，它不支持多繼承。 – Fabio

這個例子非常簡單，但在將來的某個時候，抽象類可能有一些接口可能不需要的代碼（可能是某種發佈/訂閱通知）（您現在有一些基於IEmployee的類，它不會需要觀察）。將它拆分現在將有助於未來。 – Neil

「Yagni」（你不會需要它） – Fabio

只處理屬性時的界面與抽象類

回答

相關問題