如果一個對象解析它自己的輸入，它是否被認爲是破壞SRP？

如果一個對象解析它自己的輸入，它是否被認爲是破壞SRP？如果一個對象解析它自己的輸入，它是否被認爲是破壞SRP？

例如

class A 
{ 
    int x; 
    string y; 
    float f; 
    A(string x, string y, string f) 
    { 
     this.x = int.Parse(x); 
     if (this.x < 0 || this.x > 10) 
     { 
      throw new ArgumentOutOfRangeException(); 
     } 
     this.y = y; 
     this.f = float.Parse(f); 
    } 
}

，或有一個私人的構造和使用，解析一個公共靜態方法和檢查輸入，並返回A。

而不是傳遞一個int，字符串和浮點數並解析並檢查它們是否在其他地方有效。

來源

2016-05-13 shinzou

IMO你的構造函數應該採取正確的類型，而不是做任何解析。 –

解析並創建對象的公共靜態方法呢？ @MatthewWatson – shinzou

這樣會更好，因爲你可以給它一個更具描述性的名字，而不僅僅是構造函數。但在我看來，將字符串解析爲浮點數和整數的責任屬於獲取這些字符串的代碼區域，或者屬於某些類中間的代碼。 –

打破單一責任原則嗎？不，你給出的例子是解析基本類型，構造一個基本對象，我不認爲你已經給出的示例代碼是它本身的責任。 SRP更容易解釋給定一個業務領域內的操作...

詳細說明，上面使用的解析正在處理原始數據類型，內置的基元類型解析用於促進一種基元類型轉換爲另一種。 SRP的目的不是爲了抽象這樣的核心功能，而是爲了確保代碼的設計具有單一責任。例如，當將記錄保存到數據庫時，可以編寫一個函數來拾取原始數據，將其映射到不同的表併發送電子郵件以確認輸入，這就是破壞SRP。在這個例子中我們如何避免這種情況？使用諸如存儲庫模式之類的東西來抽象出數據庫問題，使用單獨的類來管理電子郵件通信，可能使用依賴注入來確保這些組件在您的解決方案中易於互換。我會認真地嘗試和抽象基本類型的所有基本解析？

絕對不是。

如果你的代碼設計有不止一個必須改變的原因，那麼就會破壞SRP，這就是「改變理由」的基礎。在給出的示例中，如果電子郵件已更改，或原始數據或映射到不同的表，我們需要更改代碼，原因有三種。這就是說，你的構造函數或函數應該理想地接受正確的類型，可能有理由爲什麼你不能這樣做，但是如果你可以提供正確類型的值，你應該避免解析。

最後要補充的是：我看到許多開發人員在涉及到與原始類型，解析和構造對象有關的問題上掛起了一些問題，試圖確保沒有設計原則可能被破壞，如SRP。他們花了數小時仔細研究問題，結果錯過了更大的領域設計問題。儘量確保您可以看到更大的圖像，並且不會忽視應用程序體系結構。我並不是說你從不擔心這種事情，只是不要陷入在設計應用程序時忽略更大問題的陷阱。

來源

2016-05-13 07:49:23

我的意思並不是粗魯，但我很驚訝這種無意義的積極分數。「像解析這樣的低級操作更多的是與應用程序行爲相關的數據和變量管理」......這根本沒有任何意義。 – plalx

那麼你對此有何看法？ @plalx – shinzou

那麼，你成功地被粗魯的@plalx。 SRP更多地與應用程序的功能以及它所在的域的設計有關.C＃通常是一種高級語言，解析是可用的最低級別操作之一。如果你允許這樣的操作使你的解決方案變得複雜，並且讓一個好的領域驅動設計的水域變得渾濁，當它們在語言中無處不在時？不，你不應該。 –

如果我們同意解析是一項責任（因爲它引入了與數據格式相關的變化軸），那麼唯一的問題是class A是否有其他責任。如果class A具有與解析無關的其他邏輯，那麼這將表示另一個責任。

有趣的是，認爲class A已經解析並驗證了它的輸入。驗證可能是與業務需求相關的第二個變化軸。這是否違反SRP？這取決於我們認爲這兩個軸獨立變化的可能性。

來源

2016-05-16 00:02:53 jaco0646

這是一個比我更簡潔的答案，我同意 –

如果一個對象解析它自己的輸入，它是否被認爲是破壞SRP？

回答

相關問題