單一責任（SRP）與告別別問（TDA）？

Question

我瞭解許多設計原則在某些情況下相互衝突。所以，我們必須權衡他們，看看哪一個更有利。 直到現在我知道SRP的原則，並做了我的設計很多基於這一點，但內部我感覺有時錯誤，而遵循 這個原則。現在我來了解TDA，我的感覺了與:)

SRP更多的支持： -對象應該擔心自己的關注不是其他任何人

TDA： -行爲（這是依賴於它的對象狀態）應該保持在對象本身內

例如： -我有不同的形狀像矩形，正方形，圓等現在我必須計算面積。

我的設計一直到現在： -我跟着SRP，在那裏我有AreaCalculatorService類，它會詢問狀態並計算面積。這種設計背後的原因是形狀不應該擔心面積計算，因爲它不是形狀責任。但理想情況下，我曾經認爲區域計算代碼應該駐留在每個形狀 下，如果下線，如果出現新形狀，我必須修改AreaCalculatorService類（違反Open for extension並關閉修改原則（OECM））。 但總是優先考慮SRP。這似乎是錯誤的

神話被打破（至少我的）： -有了TDA，看起來像我的感覺是正確的，我不應該問有關對象的狀態，但告訴形狀來計算它的面積。雖然 它將違反SRP原則，但將支持OECM原則。正如我所說的設計原則有時相互衝突，但我相信行爲 完全依賴於它的對象狀態，行爲和狀態應該在一起。

又如： -說我要計算組織中的所有員工的所有部門的工資，那麼我們就應該遵循SRP其中SalaryCalculatorService 將取決於部門和員工。

它會詢問每位員工的工資，然後對所有工資進行彙總。所以在這裏我要求的是員工的狀態，但 仍然沒有違反TDA calcSalary不僅僅依賴於每個員工的工資。

讓我知道，如果我對這兩個原理的解釋是正確的，我應該在第一種情況下遵循TDA，而在第二種情況下應該遵循SRP？

Answer 1

我認爲你對TDA的理解是正確的。 問題在於SRP，根據我的經驗，這是最誤解的SOLID原則。 SRP說，一個班級應該只有一個改變理由。 「改變理由」部分經常與「應該只有一個責任」混淆，所以「它只能做一件事」。不，不是這樣的。
「更改原因」完全取決於類所在應用程序的上下文。特別是它取決於與軟件進行交互的角色，以及將來可能會要求進行更改。
參與者可以是：支付軟件的客戶，普通用戶和一些超級用戶。管理應用程序數據庫的DBA或處理應用程序運行硬件的IT部門。一旦你列舉了軟件中的所有參與者，爲了遵循SRP所說的，你必須以只有一個責任的方式編寫你的類，因此只有來自一個參與者的請求可能需要對你的類進行一些修改。
所以，我認爲你應該遵循TDA把這些數據放在同一個對象中的數據和行爲。通過這種方式，您可以管理對象之間的關係，告訴他們做什麼而不是詢問數據，減少耦合並達到更好的封裝。
如上所述，SRP將指導您決定將哪些行爲放入一個對象而不是另一個對象。