使用自動實現的屬性超過手動實現的屬性的任何原因？

我明白PROPERTIES超過FIELDS的優點，但我覺得使用AUTO實現的屬性而不是MANUAL實現的屬性並沒有真正提供任何優勢，除了使代碼更簡潔一些以外。使用自動實現的屬性超過手動實現的屬性的任何原因？

我感覺舒服多用：

private string _postalCode; 

    public string PostalCode 
    { 
     get { return _postalCode; } 
     set { _postalCode = value; } 
    }

相反的：

public string PostalCode { get; set; }

主要是因爲如果我想要做的任何種類的獲取和設置的自定義實現的，我要創建無論如何由私人領域支持我自己的財產。那麼爲什麼不從一開始就咬住子彈，並立即給予所有屬性這種靈活性，以保持一致性？考慮到您在Visual Studio中所做的所有操作都是單擊您的專用字段名稱，然後按Ctrl + E，即可完成，但這並不需要額外的時間。如果我手動執行，那麼最終會出現不一致性，其中有一些由專用字段支持的手動創建的公共屬性，以及一些自動實現的屬性。無論是全自動還是全部手動，我都感覺好多了。

這是我嗎？我錯過了什麼嗎？我誤解了什麼嗎？我是否過分強調一致性？我總是可以找到關於C＃特性的合法討論，幾乎總是有優點和缺點，但在這種情況下，我確實找不到任何推薦使用自動實現屬性的人。

來源

2011-11-14 CptSupermrkt

你說你現在可以這樣做 - 因爲將來你可能必須這樣做。爲什麼浪費時間做一些容易出錯的東西（你可能最終會複製和粘貼），只有在需要時才能做到這一點？ – Rob

感謝羅布。我的推理是，使用Visual Studio，只需一次額外的按鍵即可創建手動實現的屬性，因此不會複製/粘貼。如果有一天我確實需要創建自己的實現，那麼我不會在自動實現的屬性和手動實現的屬性之間產生分歧，它是100％或100％。通過從一開始就充分利用手冊，我可以隨時創建自己的實現，而無需自動實現某些屬性，並且某些屬性是手動的。當然，我明白你的觀點。 – CptSupermrkt

在這種情況下，我和你一起堅持100％的手動執行。在VS 2010（至少）中遇到手動獲取/設置器 – Rob

除簡潔之外，它不會給你任何額外的東西。如果你更喜歡更詳細的語法，那麼一定要使用它。

使用自動道具的一個好處是，它可以使您避免犯一個愚蠢的編碼錯誤，例如意外地將錯誤的私有變量分配給屬性。相信我，我已經做到了！

你對汽車道具不太靈活的觀點是不錯的。您擁有的唯一靈活性是通過使用private get或private set來限制範圍。如果你的吸氣者或安裝者對他們有任何複雜性，那麼汽車道具不再是一個可行的選擇。

來源

2011-11-14 03:24:57

非常感謝，這幾乎清除了它。 – CptSupermrkt

根據我的經驗，公共屬性讓人們擺脫了面向對象的思維。我現在所做的一個項目有一些對象，只有一些屬性初始化了一些屬性，所以如果該屬性爲null或者不是，並且代碼庫中有很多區域檢查null。我認爲它們對於某些情況非常有用，如果我強調它們似乎是魔鬼。 – CodyEngel

@CodyEngel不保證通過訪問者訪問的對象也不是null。如果人們會用屬性編寫潦草的代碼，他們會不編寫潦草的代碼。 – iheanyi

有人think that automatic properties can be somewhat evil但除此之外他們只是語法糖。除了保存幾行代碼之外，使用它們並不會帶來任何好處，您可以爲自己創建更多的工作（因爲您希望執行一些檢查或引發事件，因此必須手動實現它）。一致性在編程（imho）中非常有用。

來源

2011-11-14 03:28:53 ChrisWue

啊，所以有關於這個地方的討論:)謝謝你的鏈接！ – CptSupermrkt

我不知道別人，但我傾向於暫停時間去思考我應該的名字我變量和功能，以便其他人可以理解我的代碼。

所以，當我使用汽車 -implemented性質，我只有一次暫停。

當我需要支持字段我需要停下來兩次，所以它會減慢發展有點:)

我做到這一點的方法是：

使它成爲一個私有變量在開始時
如果需要，請將其更改爲公開自動實施。
如果我需要獲取或設置一些代碼，請將其更改爲後臺字段。

如果一個類的不同屬性暴露不同，沒有任何錯誤。

來源

2011-11-14 03:32:09

您將失去控制權的事情之一是能夠將後臺字段指定爲NonSerialized，但在此情況下爲屬性創建後臺字段很容易。

忘記：如果您或您使用的任何產品在成員（即WCF）上執行反射，那麼您將看到損壞的支持字段名稱，而不是您創建的「漂亮」支持字段。

如果您之前提供了對服務的訪問權限，或者如果您在接收端反序列化爲相同的類結構（即在WCF管道的兩端使用相同的類），這可能非常重要。在這種情況下，您不一定能夠反序列化，因爲您可以保證支持字段名稱是相同的，除非您共享相同的DLL而不是源代碼。

再澄清一點：假設您有一個Web服務，通過WCF將您的一些業務對象公開給您創建的Silverlight客戶端。爲了重用您的業務邏輯，您的Silverlight客戶端會添加對業務對象源代碼的引用。如果您有自動實現的屬性，則無法控制後備字段名稱。由於WCF序列化成員而不是屬性，因此無法確定從WCF服務傳輸到Silverlight的對象是否會正確反序列化，因爲支持字段名稱幾乎肯定會不匹配。

來源

2011-11-14 04:00:20

自動實現的屬性不保證在構建之間保持相同的後臺字段名稱。因此，理論上可能會在一個版本的程序集中序列化一個對象，然後在另一個程序集中重新序列化同一對象可能會導致重大更改。

這是高度不太可能，但如果您試圖保持爲新版本「換出」您的程序集版本的能力，這是一個有效的擔憂。

通過使用手動實現的屬性，可以保證後臺字段永不改變（除非您專門更改它）。

除了那個微小的差異，自動屬性是一個正常的屬性，是自動實現的後臺字段。

來源

2011-11-14 04:14:34

我看到使用自動屬性的優勢之一是;在調試應用程序時，它不會進入不必要的獲取/設置部分。我知道我們可以使用Debugger Attributes或Step over來避免相同的情況;但是，如果在大型應用程序上進行調試，則會發生大多數情況。

來源

2011-11-14 05:11:54 Riju

使用自動實現的屬性超過手動實現的屬性的任何原因？

回答

相關問題