今回は単一責務の原則に違反している例を見ていきたいと思います。
1.1 単一責務の原則に違反している例
画面プログラムにデータアクセス，表示，メール送信など詰め込んでいるクラス
例えばってことでここに，ちょっと巨大なクラスのイメージで書いています。例えば受注画面クラスですね。実装はWindowsフォームとか，WPFとか何でもいいですけど，画面があって受注画面クラスがあるという状況を考えてください。
その受注画面で，「受注データ入力し，データベースに登録して，登録したらメール送信する」みたいな感じの仕様があった場合です。「１個の画面クラスに全部の機能を詰め込んでみましょう」という感じで書いたら，1つのクラスに収まってくる訳なのですが，この状態で原則に当てはめてチェックしてみましょう。
単一責務の原則
・クラスの責務は１つ
・クラスの変更理由は１つでないといけない
今回の原則で言うと，クラスの責務は１つのわけです。クラスの変更理由は１つでないといけないとうことですね。
責務＝変更理由：ここには複数の変更理由がある
この責務というのはというと，「変更理由」というふうに言われています。１つの責務ってことは，変更理由も１つ。複数の変更理由があるということは，責務も複数あるという意味ですね。
今回のこの例では，複数の変更理由が存在していますよということですね。
データベースへのアクセス
まずはデータベースへアクセスしていますね・・・
クラス図の中に，受注データをデータベースへ登録というのがありますけど，このデータベースの仕様が変わったりとか，CSVに登録したくなったりとか，いろいろあると思うのですけど，そういう保存形式が変わったり，仕様が変わったりしたら，この受注画面クラスを変更しないといけないですよね。
メール送信
メール送信時の仕様変更
→メール送信時は管理者にCCで送信する
メール送信の責務もあるため，メール送信時の仕様が変わったら，例えばメール送信する時に，「CCで管理者付けようね」みたいな仕様が追加されましたのであれば，メール送信の仕様が変わっても，この受注画面クラスをいじらないといけないということになります。
画面コントロールの入出力
テキストボックスを別のコントロールに変更する
どの変更があっても，受注画面クラスを修正することになる
このクラスは画面なので，画面コントロールの入出力の責務もあります。テキストボックスにテキストを表示したり，入力を受け付けたり，登録ボタンが押されたりという責務があります。このテキストボックスを，違うテキストボックスにしたくなった場合，当然この受注画面クラスというのは，修正することになります。
このクラスには複数の責務があるため原則違反
ここまで見てきたように，このクラスは複数の変更理由があり，複数の責務が存在するため，原則違反ということなのです。ですので，クラスを作る時は，変更理由が１つなのかというところを意識して設計しようねというのがこの原則ということになります。