在以下範例中對單一責任原則感到困惑
在下面的影片中，作者採用了一個現有的類並將單一責任原則分配給它。他參加了一個列印類，該類的任務是訪問數據、格式化和列印報告。他將每個方法分解為自己的類，因此他創建了一個 DataAccess 類來處理數據訪問，他創建了一個 ReportFormatter 類來處理報表的格式，他創建了一個 ReportPrinter 類來處理報表的列印。原來的 Report 類只剩下一個方法 Print()，它呼叫 ReportPrinter 的類方法 Print。DataAccess 和 ReportFormatter 似乎有責任，但 ReportPrinter 依賴於 DataAcess 和 ReportFormatter，所以這不會破壞 SRP 還是我誤解了它？
單一職責原則表明給定的類應該有單一職責（或“改變的理由”）。它本身並沒有表明如何履行這一責任。這樣做可以而且經常需要多個其他班級作為合作者的合作。
不看影片，這聽起來像是一個合理的設計。SRP 沒有被破壞，因為處理數據訪問的方法沒有出現在 ReportPrinter 類中，只有“我可以呼叫某些東西來獲取我想要的數據”的概念。
您可以將它推得更遠一點，並有一個協調器類只負責協調數據訪問類、格式化程序類和列印機類的活動。您還可以以不同的方式排列對象，例如讓協調器將數據發送到格式化器，格式化器將其發送到列印機，而協調器不（直接）知道列印機。
關於協調狹隘對象的努力，必須知道一些事情。這成為他們的責任。只要您不知道或不關心它們是如何做的，就可以了解其他對象將要做什麼的想法或概念。將介面視為“責任接縫”是一個好的開始。
如果您將對象視為相互傳遞數據而不是“做”事情，這也會很有幫助。因此，ReportFormatter 返回（或轉發）一個表示格式化報表的新對象，而不是（從概念上）在現有報表上執行對象。