2009-12-09 38 views
1

我正在推遲一位同事的設計,並且想知道在這種情況下誰的SRP應用是正確的。單一責任原則(SRP)在何種抽象層次上不再有意義?

我看到SRP主要與較低層次的設計細節有關,例如階級責任。隨着抽象層次的提升,我認爲SRP仍然是相關的,但是單一責任的定義必然也會向更高的抽象層次發展。

在我的具體情況中,「處理foos,存儲結果並提供對這些結果的訪問權限」的服務具有「foo處理子系統」的單一責任,但是一位同事不同意並將其視爲2-3個獨立的職責。我的情況是,如果你總是將單一責任分解爲細節,那麼擁有「銀行」是SRP的違規行爲,因爲它「持有資金,維護賬戶,出售抵押貸款......」。

+0

看到這個問題,它的答案是:http://stackoverflow.com/questions/2455705/how-do-you-determine-how-coarse-or-fine-grained-a-responsibility-should-be-when – User 2011-07-23 00:18:55

回答

2

像許多軟件設計原理一樣,這在我看來似乎是非常主觀的,但經常爭辯說它好像不是。 「單一責任」定義不明確,取決於您認爲的責任。有時候,一段代碼顯然做得太多了,而且有一個鉤子來掛起這個問題是有幫助的,但是假裝它總是一個剪切乾的評估是愚蠢的。

1

我認爲你可能是對的,但不能用這個原則來解決你的爭議。羅伯特馬丁把責任定義爲「改變的理由」。如果foo的結構發生變化(例如,添加了一個字段),您希望更改反映在該類中。在你的同事的方法中,所有的課程都必須改變。這是原則必須在應用層的上下文中應用的原因,因爲它也會改變顯示代碼,顯然它們不應該在同一個類中。如果存儲機制發生變化(例如,使用不同的數據庫驅動程序),我希望通過持久性配置對其進行外部處理,所以只需保留其他原因以便改變課程外,所有人都可以很開心。

+0

在這種情況下,不存在涉及表示層(不在此子系統之外),但它確實結合了來自處理的數據處理和元數​​據存儲。我的觀點是,我認爲這是關於上下文/參考框架的。在這個子系統內的較低層次當然應用了SRP,但是SRP似乎傾向於荒謬的是當這些組件在整個系統的上層到達之前從未被連成一個更高層次的內聚單元。 – archie 2009-12-09 19:43:07

+0

我不確定這是一個很好的比喻,但在大腦中,我發現個體腦細胞有單一的責任,並且相鄰的細胞羣被組合成更高層次的單位,而這些單位具有其他單一但更高層次的責任,並且這個低層次的單位會一直持續到你有一個完整的大腦。我現在感覺的SRP-absordium會有一個扁平的大腦結構,它將數十億個細胞連接在一塊意大利麪條上。也許這就是SRP變得太過分了......意大利麪條業務邏輯......? – archie 2009-12-09 19:43:46

0

我會同意你的同事在這種情況下。存儲和處理應該分開,因爲兩者有不同的「改變原因」。

至於你給的銀行例子,我會爭辯說銀行不賣賣出抵押貸款。貸款部門(或其他)出售抵押貸款,銀行有一個貸款部門。將「銀行」視爲一個單一對象相當於一個人經營整個銀行。

0

我不同意你的同事。

單個責任的粒度應該與您正在建模的級別相匹配。隨着抽象層次的提升,責任的粒度也應該向更高的抽象層次發展。

至於銀行的例子,其單一職責將提供金融服務。

這個概念就像一個工作分解結構。當你下降並「看」一系列部門時,他們將有自己的單一責任。因此,責任也可以分解。重要的是,細分是一致的。

相關問題