それでは，前回解説した「原則違反の例」の受注画面クラスを，変更理由単位でクラスを分けてみましょう。
1.1 変更理由ごとにクラスを分ける
前回解説した通り，受注画面クラスにはデータベースへのアクセス，メール送信，画面コントロールの入出力という３つの変更理由があることがわかったので，それぞれのクラスに分割してみます。
データベースへのアクセス部分
データベースではなくCSVへ登録するように変更
「データベースかな」とか「CSVかな」とかというのが，変更するかもしれないというのであれば，この受注出データアクセスクラスというのを分けておけばいいわけですね・・・
受注画面クラスの中で，データベースにアクセスするのではなく，データベースの受注データにアクセスするという単独のアクセスクラスを作ります。
メール送信部分
あとはメール送信をしているわけなので，このメール送信も独立して作れるよねと・・・
独立したメール送信クラスを作成することで，メール送信するときの仕様が変わっても，ここをいじればいいよねということになってきます。
画面コントロールの入出力
テキストボックスを別のコントロールに場合などの変更理由は，これに関しては，受注画面クラスにあるわけなので，これが変わったら受注画面クラスを変えるのは，仕方がないよねということで，画面のコントロール関係は受注画面クラスに残したままとします。まとめると次の図のように３つのクラスに分かれました。
これが変更理由に着眼点を置いたクラス分割ということになります。