単一責務の原則

オブジェクト指向の原則 単一責務の原則 #01単一責務の原則とは

それでは「単一責務の原則」について解説をしていきたいと思います。

1.1    単一責務の原則

SRP: Single Responsibility Principle 

クラスの責務は1つにする

この原則は,基本的に「クラスの責務は1個にしようね」という原則です。あと別の切り口で言うと,「変更理由を1つにしましょう」というふうによく言われています

クラスの変更理由は1つでないといけない

「クラスの変更理由は1つでないといけない」といった感じでよく表現されます。単一責務なので,「1個のクラスに,1個のことだけをさせようね」という非常にシンプルな原則なのですけど,今回は,ここを深掘りして解説をしていきたいと思います。

意外とここを深堀していくと,ドメイン駆動開発の思想にもつながっていきますし,オブジェクトをどうやって上手く分割していくか,というところのヒントだったり,答えだったりというのが,ここにあるのではないかという風に私は思います。

「.NETのエンタープライズアプリケーションアーキテクチャ」という本が黒い本があるのですけど,その中のこの「単一責務の原則」の中では,こういう出だしで書かれています。

「クラスが大きく成長し,多くのメソッドを持つようになったら,責務の数が多すぎる可能性がある,理想の責務の数はたった1つ」ということで,要するに責務の数を1個にしましょうねということなのですが,これからその辺りを詳しく見ていきましょう。

オブジェクト指向の原則 単一責務の原則

C#を正しい3層構造で造れてますか?

非売品コースを受け取る

#00_はじめに
#01_単一責務の原則とは
#02_原則違反の例
#03_変更理由単位でクラスを分ける
#04_3層構造の例
#05_修正箇所を最小にできる
#06_修正する場所が明確になる
#07_共通化しましょうという話ではない
#08_少々悪いコードでも問題視しない理由
#09_探しやすいコード
#10_クラスは機能ごとに小さく作る
#11_小さなクラスがそれぞれに協調して目的を達成させる
#12_多数の部品群のなかから摘まんで作る
#13_クラスはどこまで小さくすればいいのか
#14_アンダーソン式単一責務の原則
#15_最小カプセルの検証_監視タイマークラス
#16_最小カプセルの検証_受注画面クラス
#17_最小カプセルの検証_ユーザークラス
#18_最小カプセルの検証_商品マスターデータアクセス
#19_登場人物に合わせたモデリングの四角と線
#20_四角と線を最小カプセル化する
#21_アンダーソン式手順
#22_パターンを見つけ出す
#23_プログラミングの自問
#24_さいごに

【参考図書】ピーコックアンダーソンが参考にした書籍一覧