總是使用自定義數據類型

我想知道它是否瘋狂（幾乎）總是在C＃中使用自定義數據類型，而不是依賴於內置類型如System.Int32和System.String。總是使用自定義數據類型

例如，要表示一個人的名字，其思想是使用名爲PersonFirstName而不是System.String的數據類型（當然，PersonFirstName數據類型必須包含System.String）。另一個例子是擁有一個PersonID類，它代表該人員的數據庫標識符，而不是擁有System.Int32。

會有一些好處在這裏：

今天，如果一個函數有一個int參數，它很容易在公司的對象，而不是一個Person對象的ID的ID來傳遞，因爲兩者都是int類型。如果函數使用了CompanyID，那麼如果我嘗試傳入PersonID，則會出現編譯錯誤。
如果我想將數據庫列數據類型從int更改爲person的uniqueidentifier，那麼我只需要在PersonID類中進行更改。今天，我將不得不在所有需要一個Int並且應該代表一家公司的地方進行更改。
在正確的位置實施驗證可能會更容易。「」可能永遠不會是PersonFirstName可以照顧的正確的名字。

是的，我將不得不寫更多的構造函數。我可以在這些實現隱式重載，使他們很容易處理。

這是瘋了嗎？

來源

2009-11-10 Martin

你說的是創建對象來描述您的問題eleemnts域？對這個問題有點困惑 – 2009-11-10 13:51:24

我在說自定義類來描述我在軟件中使用的* all *變量，而不是僅僅爲了主o域中的對象。不僅僅是Car-class和Person-class，還要創建CarID類，它代表汽車的ID，代表板的CarPlate類，代表顏色的CarColor類等等。 – Martin 2009-11-10 13:53:58

好主意，因爲它可以防止您意外地爲項目數分配一個郵政編碼，或者這樣的郵政編碼 – 2009-11-10 14:23:24

是的，絕對的瘋狂 - 總結一下你的想法，並套用黑爵士

它瘋了！這很生氣。它比瘋狂的傑克McMad，今年的狂人先生競爭

來源

2009-11-10 13:50:47 Ian

很好的反饋！ :) – Martin 2009-11-10 13:54:40

+1使用BlackAdder ... – 2009-11-10 13:55:26

雖然我發現問題措辭不幸，根本上我覺得這個概念有價值 - 尤其是在DDD社區。 'ProductId'，'CustomerId' * types *沒有聽起來那麼瘋狂。閱讀http://dddcommunity.org/sites/default/files/pdf_articles/Vernon_2011_2。PDF（PDF）的一些很好的例子。 – Matt 2012-05-03 21:58:11

是的，瘋狂和矯枉過正的贏家茜草...

來源

2009-11-10 13:51:29

不，你沒有得到的任何實際的好處。對於某些事情來說它是有道理的，也許是一個電子郵件類或可能是一個ID類。但是，有一個「PersonID」或「ClientID」類似乎走得很遠。你可以有一個「typedef」或別名，但在大多數情況下，我不會太過分。你可以非常快速地過度，最終得到很多工作，沒有任何好處。

來源

2009-11-10 13:51:48 BobbyShaftoe

你是什麼意思，我不會得到任何真正的好處？ typedef或別名不能解決我列出的好處1和3。能夠區分PersonID和CompanyID可能是一個真正的好處，對吧？在一端，我們使用字符串來處理所有事情。在另一端，我們使用自定義數據類型的一切。最佳的方式是在中間的某個地方，對嗎？ – Martin 2009-11-10 13:59:21

System.Net.Mail.MailAddress for emails;） – Ian 2009-11-10 13:59:54

@Martin，你的投訴幾乎是有趣的，但我確實解決了這些問題，說可能有一些情況，比如在電子郵件類或其他情況下。毫無疑問，你提出的建議是「解決1和3」問題，但是爲了提供你需要的好處來解決實際上可能會影響到你的問題。你所問的事實表明你認爲這可能不夠有益。 Typedefs用於這種事情，但他們不解決1和3的問題;他們並不是要解決「我不小心通過錯誤類型」的問題。 – BobbyShaftoe 2009-11-10 15:34:37

是的......是！你會失去更多的收益。

來源

2009-11-10 13:51:59 Dani

你真的親自做過這個或者你在猜測嗎？ – Martin 2009-11-10 13:55:23

如果您正確構建軟件，還有其他方法可以確保正確的值不會出現在錯誤的字段中。我通常爲DB中的所有表和列名生成類（因此在編譯時會檢測到這些錯誤），並且對所有變量和屬性使用有意義的名稱 - 即使是臨時的，我也有單元測試，它始終檢查所有內容，通常如果我有一些關於我在Setter中使用它的知識 - 來驗證它。如果它非常非常重要 - 我使用枚舉 - 這與您所做的相似。 – Dani 2009-11-10 14:54:03

這聽起來像是我的維修噩夢。 CompanyID構造函數將採取什麼措施？一個整數？遲早 - 你將不得不使用原生類型，不管你喜不喜歡。

來源

2009-11-10 13:52:10

當然，在某些時候，軟件將不得不關心本地類型。但在我的情況下，這將由OR映射器處理。 – Martin 2009-11-10 13:56:25

我不認爲這是瘋狂。我認爲使用業務邏輯對象與強類型對象是非常好事

來源

2009-11-10 13:52:19 Chad

+1。爲「幾乎所有」案件做到這一點將是瘋狂的。但是引用的例子很有意義。這是標準的重構之一，ExtractClass http://www.refactoring.com/catalog/extractClass.html – MarkJ 2009-11-10 13:59:11

@MarkJ：它*對於引用的例子沒有什麼意義。如果OP希望OO的好處和強大的輸入，那麼答案就是傳遞'Person'對象而不是單個'int'和'string'成員。創建大量無用的單字段'PersonFirstName'，'PersonID'等對象*不是*重構，*不是一個明智的解決方案。 – LukeH 2009-11-10 14:41:38

所以，我在這裏看到的第一眼是一個問題中的一個問題。基本上：

如何緩解我的代碼庫中的複雜性和更改？

我想說，你需要看看你正試圖解決的問題，並首先看看最好的解決方案是什麼。如果您正在處理的事情可能會遍及整個代碼庫，那麼您可能需要查看是否違反了SOLID設計原則。如果你有一種類型在很多不同的地方被使用，那麼你的設計就會被耦合起來，並且你的關注點分離很差。另一方面，如果你知道這種類型將在很多地方使用，並且它也會非常不穩定（變化是肯定的），那麼你上面提到的方法可能是正確的要走的路。

問問自己「我想解決什麼問題？」然後根據該答案選擇一個解決方案。不要從答案開始。

來源

2009-11-10 14:00:16 Josh

我沒有問題，我試圖解決。我只是想回答我的問題。 – Martin 2009-11-10 14:02:32

如果你正在尋找一個直接的答案，那麼我不能給你一個。正如你從其他答案中看到的那樣，有分歧的餘地。然後可以推斷答案僅取決於手頭的問題。我只是試圖強調解決方案比其他解決方案更適合的情況。盲目表明一種解決方案比另一種解決方案更優越，並導致教條主義。所有的設計決策都需要根據自己的優點和缺點加以理解，以便對何時或不使用它們做出明智的決定。 – Josh 2009-11-10 14:14:47

如史蒂夫奈爾從Code Complete提取：

的面向對象的設計會問，「如果一個ID被視爲一個對象？」根據項目的編碼標準，「是」的答案可能意味着編程必須編寫一個構造函數，並對其進行評論;並將其置於配置控制之下。大多數程序員會決定：「不，不值得爲一個ID創建一個類，我只是使用整數。」

注意剛發生的事情。一種有用的設計替代方法，即簡單地隱藏ID的數據類型，甚至沒有考慮過...

對於我來說，這段話是一個偉大的回答你的問題，我完全贊成。

來源

2012-05-03 22:09:51 Matt

總是使用自定義數據類型

回答

相關問題