それでは，前回解説した「原則違反の例」の受注画面クラスを，変更理由単位でクラスを分けてみましょう。
1.1 変更理由ごとにクラスを分ける
前回解説した通り，受注画面クラスにはデータベースへのアクセス，メール送信，画面コントロールの入出力という３つの変更理由があることがわかったので，それぞれのクラスに分割してみます。
データベースへのアクセス部分
データベースではなくCSVへ登録するように変更
「データベースかな」とか「CSVかな」とかというのが，変更するかもしれないというのであれば，この受注出データアクセスクラスというのを分けておけばいいわけですね・・・
受注画面クラスの中で，データベースにアクセスするのではなく，データベースの受注データにアクセスするという単独のアクセスクラスを作ります。
メール送信部分
あとはメール送信をしているわけなので，このメール送信も独立して作れるよねと・・・
独立したメール送信クラスを作成することで，メール送信するときの仕様が変わっても，ここをいじればいいよねということになってきます。
画面コントロールの入出力
テキストボックスを別のコントロールに場合などの変更理由は，これに関しては，受注画面クラスにあるわけなので，これが変わったら受注画面クラスを変えるのは，仕方がないよねということで，画面のコントロール関係は受注画面クラスに残したままとします。まとめると次の図のように３つのクラスに分かれました。
これが変更理由に着眼点を置いたクラス分割ということになります。
Udemyの非売品コース「C#14新機能」という80分の動画レクチャーを
無料でプレゼントしています。
こちらからご覧になってみてください。
A01_はじめに
B01_メッセージを出すレイアウトの作成
B02_pタグを使ったメッセージ表示
B03_ポップアップメッセージを表示する方法
B04_問い合わせメッセージを表示する方法
B05_ユーザーの入力を受けるメッセージ
B06_インラインJavaScript非推奨
B07_Javascriptを分離してアクセスする方法
B08_MessageServiceを作成する
B09_自作Serviceの依存性注入をする方法
C01_EditFormを使った入力検証
C02_ValidationSummary
C03_ValidationMessage
C04_入力コンポーネント_InputText
C05_InputNumber
C06_未入力を許容する方法
C07_InputNumberで対応している型
C08_InputDate
C09_InputSelect
C10_入力コンポーネント_InputCheckbox
C11_InputRadioとInputRadioGroup
C12_InputTextArea
C13_InputFile
C14_ファイルの上限を設定する
C15_フォーカスをあてる方法_標準編_ElementReference
C16_フォーカスをあてる方法_Razorコンポーネント編
D01_StringLength
D02_RegularExpression_正規表現
D03_EmailAddress
D04_Compare
D05_ViewModelに分ける方法
D06_依存性注入を利用したViewModelの生成
D07_CustomValidation1
D08_CustomValidation2
D09_プロパティレベルのCustomValidation
D10_ValidationContext
D11_処理をViewModelに移す書き方
D12_ViewModelに移せないロジック
D14_ShouldRender
D15_ViewModelに書かないほうがいいもの
D16_エラー箇所にフォーカスを当てる方法
E01_Azureにデプロイするための事前作業
E02_Azureにアップするアプリの作成
E03_Azureへの公開準備
E04_Azureへの公開
E05_データベースの作成
E06_データベースのデータを取得する
E07_データベースの値を画面に表示する
E08_Azureのデータベースを作成する
E09_Azureのデータベースにポータルサイトからログインする
E10_AzureのDBにテーブルを作成する
E11_BlazorアプリからAzureDBに接続する
E12_SQLデータベース料金の注意
E13_AzureSQLデータベースの無料オファーを受ける
F01_依存性注入のライフサイクル
F02_クラウドでのAddSingletonの動き
Udemyの非売品コース「C#14新機能」という80分の動画レクチャーを
無料でプレゼントしています。
こちらからご覧になってみてください。