2009-08-13 87 views
13

每當有關於屬性的信譽問題,我看到大部分的討論情況各地函數/方法VS屬性。但我也想知道引人注目理由使用性質相關的私人領域與公開場直接本身,櫃面最常見的get/set行爲,沒有其他的處理,我的意思是這樣地產(沒有額外的處理)與公共領域

public string CustomerName; 

VS

private string customerName; 
public string CustomerName 
{ 
get{return customerName;} 
set(string value){this.customerName=value;} 
} 
+5

你也可以做「public string CustomerName {get; set;}」 – cyberconte 2009-08-13 15:01:52

回答

22

你得到源/二進制兼容性,如果您以後需要添加其他的行爲,你能添加破發點,這是(約的行爲,而不是存儲機制保健)只是哲學乾淨。

注意,你不需要整個後半模塊的C#3:

public string CustomerName { get; set; } 

更多信息請參見my article on "Why Properties Matter"

+0

Jon ..我明白你的觀點。但不知何故,我覺得代碼將是另一種方式即清潔,如果有在課堂上更多的領域(比如30+),那麼代碼行數是4 ATLEAST倍以上的有屬性。現在C#3和VB 10中的自動屬性讓我們所有人都快樂! – Raj 2009-08-13 15:16:20

+7

如果您的班級中有30個字段,那麼您應該先使用更多的封裝。 – 2009-08-13 15:32:11

+1

只是爲了確認我是否理解封裝的正確性,將單個類中大字段的邏輯子集分組到不同的類/接口中,並通過繼承或組合來獲取這些子字段。那是對的嗎?如果是這樣的話,那麼仍然會包含額外的代碼,而這些代碼被分散到不同的類中,而不是一個類中。對不起,如果我用廢話來惹你。這都是因爲我在維護其他人編寫的成千上萬行代碼(帶有許多沒有額外邏輯的屬性)時感到沮喪。 – Raj 2009-08-13 15:47:51

3
  1. 您可以覆蓋或在派生類中

  2. 至少創建一個「新」的屬性在這一點上人們期望的屬性被暴露和字段被隱藏。如果有人想要反思你的課程(它變得越來越常見於Castle Windsor,NHibernate等工具),那麼就會有一個不同的世界,他們很可能不會檢查暴露的領域。

1

您還可以提供一些基本的屬性驗證。例如,要防止將屬性設置爲無效狀態(如高度爲負值):

private int height; 
public int Height 
{ 
    get{ return height; } 
    set 
    { 
    if (value > 0) 
    { 
     height = value; 
    } 
    } 
} 
+1

我確實同意,任何額外的處理(如驗證)都會明顯地使用屬性。這就是爲什麼我特別提到沒有這種額外處理的情況。 – Raj 2009-08-13 15:18:46

2

這主要是Java中的一個錯誤。在許多其他語言(Python中,德爾福,Groovy中),編譯器會爲你生成除非您提供的代碼的getter和setter。

這意味着你可以在Groovy中使用「公」領域,編譯器會默默地生成和調用設置/ setter方法。如果你需要在一個領域改變時做更多的魔法,你可以引入一個專門的制定者,一切都會奏效。

這是其中的一件事情讓現實的衝突與設計。 Java設計人員不希望編譯器做任何你看不到的事情。多年前似乎是一個好主意,結果並不好。

+0

注意:該問題最初缺少語言標記,因此此答案假定問題中的代碼是Java; [tag:c#]標記稍後添加。 – mklement0 2017-04-06 11:59:43

2

我注意到一個有益的使用性能。如果要將對象的集合綁定到DataGrid或DataGridView或其他可綁定控件,則唯一可識別的可計算名稱是Property而不是公用字段。