単一責務の原則

オブジェクト指向の原則 単一責務の原則 #02_原則違反の例

今回は単一責務の原則に違反している例を見ていきたいと思います。

1.1    単一責務の原則に違反している例

画面プログラムにデータアクセス,表示,メール送信など詰め込んでいるクラス

例えばってことでここに,ちょっと巨大なクラスのイメージで書いています。例えば受注画面クラスですね。実装はWindowsフォームとか,WPFとか何でもいいですけど,画面があって受注画面クラスがあるという状況を考えてください。

その受注画面で,「受注データ入力し,データベースに登録して,登録したらメール送信する」みたいな感じの仕様があった場合です。「1個の画面クラスに全部の機能を詰め込んでみましょう」という感じで書いたら,1つのクラスに収まってくる訳なのですが,この状態で原則に当てはめてチェックしてみましょう。

単一責務の原則

・クラスの責務は1つ

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

今回の原則で言うと,クラスの責務は1つのわけです。クラスの変更理由は1つでないといけないとうことですね。

責務=変更理由:ここには複数の変更理由がある

この責務というのはというと,「変更理由」というふうに言われています。1つの責務ってことは,変更理由も1つ。複数の変更理由があるということは,責務も複数あるという意味ですね。

今回のこの例では,複数の変更理由が存在していますよということですね。 

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

まずはデータベースへアクセスしていますね・・・

クラス図の中に,受注データをデータベースへ登録というのがありますけど,このデータベースの仕様が変わったりとか,CSVに登録したくなったりとか,いろいろあると思うのですけど,そういう保存形式が変わったり,仕様が変わったりしたら,この受注画面クラスを変更しないといけないですよね。

メール送信

メール送信時の仕様変更

→メール送信時は管理者にCCで送信する

メール送信の責務もあるため,メール送信時の仕様が変わったら,例えばメール送信する時に,「CCで管理者付けようね」みたいな仕様が追加されましたのであれば,メール送信の仕様が変わっても,この受注画面クラスをいじらないといけないということになります。

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

テキストボックスを別のコントロールに変更する

どの変更があっても,受注画面クラスを修正することになる

このクラスは画面なので,画面コントロールの入出力の責務もあります。テキストボックスにテキストを表示したり,入力を受け付けたり,登録ボタンが押されたりという責務があります。このテキストボックスを,違うテキストボックスにしたくなった場合,当然この受注画面クラスというのは,修正することになります。

このクラスには複数の責務があるため原則違反

ここまで見てきたように,このクラスは複数の変更理由があり,複数の責務が存在するため,原則違反ということなのです。ですので,クラスを作る時は,変更理由が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_さいごに