單一責任原則和課

我希望我能說清楚我正在努力:-)在這裏。我想知道如何在以下情況下實施SRP：單一責任原則和課

有一個項目。完成後，聯繫人必須郵寄一份調查問卷，並在其中提供有關項目進展情況的反饋。

該軟件有一個項目級。有一個循環遍歷所有項目的過程。我已將所有用於郵寄的代碼分離到名爲ContactMailer的類中，該類將項目作爲參數，如ContactMailer.AttemptMail（project）;

但是在某些情況下郵件不會被髮送：項目被標記爲DoNotSurvey或標記爲Challenged（=有人對是否發送郵件不應該發送郵件以及管理員必須做出決定）發生爭議，以及如果這種項目沒有有效的調查。

我的問題是：這個檢查可能在CheckMailConditions之類的程序中，但是這個程序屬於哪裏？它應該在ContactMailer中嗎？雖然這是一個檢查，如果應該發送郵件，這感覺有點關閉。還是應該是一個單獨的課程？這聽起來像SRP（一個有責任的類：檢查條件），但這會導致一個類有一個方法，這看起來有點過分。

或者我應該在調用ContactMailer.AttemptMail之前檢查這些條件，因爲它們是項目的屬性？我有點迷路。

在此先感謝您的想法！

來源

2013-08-07 Sebastiaan.Everyman

我不認爲你通過在你的ContactMailer類中包含檢查來打破單一職責規則。如果項目符合某些條件，它將有發送郵件的單一責任。

一個具有單一方法的類不一定是矯枉過正的，並且可能有很好的理由將檢查邏輯抽象爲一個單獨的類，這對我而言並不明顯。但是，從你所說的話來看，我認爲你的架構聽起來絕對沒問題。

就像旁邊一樣，如果你確實將檢查邏輯分成了一個單獨的類，那麼你會怎麼稱呼這個類呢？ MailConditionsChecker？根據我的經驗，如果難以想出一個明智的名詞來命名你的班級，這通常是一個不好的跡象。

來源

2013-08-07 23:49:21

感謝您的反饋，這有助於我更確定要做出選擇。有關命名困難的良好經驗法則，我會牢記在心:)您的建議名稱聽起來像我會使用的名稱。出於好奇，如上所述，將檢查邏輯抽象爲類是什麼原因？想到的一個原因是，如果有很多條件會使代碼變得混亂 - 但你也可以把它放在一個程序中。 –

我可以考慮將其分離出來的幾個原因 - 也許另一個類需要能夠共享相同的檢查邏輯。或者也許你需要能夠在某些環境/情況下運行郵件類而不用檢查邏輯，或許在測試時。 –

順便說一句，歡迎來到stackoverflow！如果答案對您有用，請記得點擊綠色箭頭接受它。謝謝。 –

單一責任原則和課

回答

相關問題