使用C＃的get set屬性被認為是好習慣嗎？

Question

我的問題很簡單，就是使用C＃的get set屬性被認為是好的，甚至比編寫getter和setter方法更好？ 使用這些屬性時，是否必須將類數據成員聲明為公共？ 我問這是因為我的教授說數據成員永遠不應該被公開，因為它被認為是不好的做法。

這個....

class GetSetExample
{
    public int someInt { get; set; }
}

vs 這......

class NonGetSetExample
{
    private int someInt;
}

編輯：

感謝大家！ 你的所有答案都幫助了我，我適當地向你投了你的答案。

Answer 1

這個：

class GetSetExample
{
    public int someInt { get; set; }
}

真的是這樣的：

class GetSetExample
{
    private int _someInt;
    public int someInt {
        get { return _someInt; }
        set { _someInt = value; }
    }
}

get; set; get; set; 語法只是一種方便的簡寫，當getter和setter不做任何特殊操作時你可以使用它。

因此，您沒有公開公共成員，您正在定義私有成員並提供get / set方法來訪問它。

Answer 2

是的，由於多種原因，成員通常不應在良好的設計中公開宣布。 想想稍后繼承該類的OOP。 有點難以覆蓋一個字段。 :-)它還可以防止你直接訪問內部。

簡單化得到; 組; 設計是在C＃2.0中引入的。 它與支持它的私有成員聲明所有內容基本相同（在Reflector等工具中反編譯它）。

public int someInt{get;set;} 

直接等於

private int m_someInt;
public int someInt{
  get { return m_someInt; }
  set { m_someInt = value; }
} 

關於使用簡化的getter / setter的重要一點是，當你想稍后用更多的內容填充實現時，你不會破壞ABI的兼容性。

不要擔心getter / setter會通過間接方式降低代碼的速度。 JIT有一個叫做內聯的東西，使用getter / setter和直接字段訪問一樣高效。

Answer 3

是。 數據成員應該是私有的，自動屬性允許它並以正確的方式提供公共訪問。

但你應該小心。 理解上下文非常重要。 在線程應用程序中，更新一個屬性跟隨另一個相關屬性可能會對一致性有害。 在這種情況下，以適當方式更新兩個私有數據成員的setter方法更有意義。

Answer 4

在您的第一個示例中，C＃自動生成私有支持字段，因此從技術上講，數據成員不會被聲明為僅公共getter / setter。

Answer 5

因為對於公共數據成員，該數據成員可以更改或者可以從類中讀取，並且您無法控制讀/寫操作可訪問性，但是使用屬性可以控制讀/寫流，例如考慮以下語句：

 public MyVar{private get; public set;}

意味着MyVar值只能在類內部進行更改，並且可以從類中讀取（私有讀取並公開讀取），這對於公共數據成員來說是不可能的

Answer 6

在“純粹的”面向對象的方法中，根本不公開對象的狀態是不行的，這適用於在.NET中實現的屬性以及Java / EJB的get_set_ properteis。 我們的想法是，通過公開對象的狀態，您將創建對象的內部數據表示的外部依賴關系。 純對象設計減少了與帶參數的消息的所有交互。

回到現實世界：如果你試圖在工作中實施如此嚴格的理論方法，你將被嘲笑出辦公室或被毆打成紙漿。 屬性非常受歡迎，因為它們是純對象設計和完全暴露的私有數據之間的合理折衷。

Answer 7

這是非常合理的，你的教授（沒有背景）是錯誤的。 但無論如何，使用“自動屬性”，很好，無論是公共還是私有，你都可以這樣做。

雖然根據我的經驗，每當我使用一個時，我幾乎不可避免地最終需要在那里寫一些邏輯，因此不能使用汽車道具。

Answer 8

你的教授是對的。

考慮一下為什么應該避免“getter”的簡單示例：程序中可能有1000次調用getX()方法，並且每個調用都假定返回值是特定類型。 例如， getX()的返回值可以放在局部變量中，並且變量類型必須與返回值類型匹配。 如果您需要以X類型發生變化的方式更改對象的實現方式，那么您就會陷入困境。 如果X曾經是一個int ，但現在必須是一個long ，你現在會得到1,000個編譯錯誤。 如果通過將返回值強制轉換為int來錯誤地修復問題，則代碼將干凈地編譯但不起作用。 （返回值可能會被截斷。）您必須修改圍繞這1,000個調用中的每一個的代碼以補償更改。 我，至少，不想做那么多工作。

Holub On Patterns