単一責務の原則

オブジェクト指向の原則 単一責務の原則 #03_変更理由単位でクラスを分ける

それでは,前回解説した「原則違反の例」の受注画面クラスを,変更理由単位でクラスを分けてみましょう。

1.1    変更理由ごとにクラスを分ける

前回解説した通り,受注画面クラスにはデータベースへのアクセス,メール送信,画面コントロールの入出力という3つの変更理由があることがわかったので,それぞれのクラスに分割してみます。

データベースへのアクセス部分

データベースではなくCSVへ登録するように変更

「データベースかな」とか「CSVかな」とかというのが,変更するかもしれないというのであれば,この受注出データアクセスクラスというのを分けておけばいいわけですね・・・

受注画面クラスの中で,データベースにアクセスするのではなく,データベースの受注データにアクセスするという単独のアクセスクラスを作ります。

メール送信部分

あとはメール送信をしているわけなので,このメール送信も独立して作れるよねと・・・

独立したメール送信クラスを作成することで,メール送信するときの仕様が変わっても,ここをいじればいいよねということになってきます。

画面コントロールの入出力

テキストボックスを別のコントロールに場合などの変更理由は,これに関しては,受注画面クラスにあるわけなので,これが変わったら受注画面クラスを変えるのは,仕方がないよねということで,画面のコントロール関係は受注画面クラスに残したままとします。まとめると次の図のように3つのクラスに分かれました。

これが変更理由に着眼点を置いたクラス分割ということになります。

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

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_さいごに