2008-11-08 75 views
4

我已經看到了(和使用)的各種項目這個佈局,其次是一組屬性的一組字段:你是否將私人領域分組或將他們與他們的財產?

private int MyIntField; 
private string MyStringField; 

public int MyInt { 
    get { return MyIntField; } 
    set { MyIntField = value; } 
}  
public string MyString { 
    get { return MyStringField; } 
    set { MyStringField = value; } 
} 

而且我以前也遇到過這種佈局,場旁邊自己的財產:

private int MyIntField; 
public int MyInt { 
    get { return MyIntField; } 
    set { MyIntField = value; } 
}  

private string MyStringField; 
public string MyString { 
    get { return MyStringField; } 
    set { MyStringField = value; } 
} 

是否有理由認爲一個比另一個更好?我認爲大多數編碼標準都推薦了選項#1,但有時候在擁有對其進行操作的屬性旁邊的區域方便。

注:我假設不平凡的屬性,不能使用自動實現的屬性。

+0

另請參見[訂單的項式類字段 - 屬性 - 構造的方法](http://stackoverflow.com/questions/150479/order-of-items-in-類字段 - 屬性 - 構造的方法) – nawfal 2013-06-04 06:30:08

回答

7

我認爲這是任何團隊感覺舒適。解決項目/公司/語言的標準並堅持下去。我更喜歡所有的私有變量,方法/接口在一起,私人成員....我認爲你明白了。

4

我將它們分組在課程的頂部。

事實上,唯一超過我的私人屬性是所有類的常量。

2

我會採用後一種方法,因爲這是一個幫助我一眼就能看出私人成員是否擁有公共getter/setter的約定。不過,這兩方面都不是很大。

1

爲了重申Kenny上面所說的,這完全是關於您組織的編碼標準。儘管每個人似乎都有自己的看法,但很難客觀地將一種風格歸類於另一種風格。

我通常更傾向於通過訪問修飾符來擁有數據和方法組,因此在這種情況下會更喜歡選項#1。這是爲了強調界面,而不是設計。也就是說,我可以在將來透明地更改MyInt修飾符的實現(也許我不需要存儲一個支持變量)。

3

我有點喜歡把字段分組在頂部,並在其他地方的屬性。這也是Microsoft StyleCop推薦的。

相關問題