〜設計後の部品を実装する1〜ツイート今回は、役割分担を行なった後にクラス(部品)をどのように組み合わせてアプリを作成するか?について記載したいと思います。【補足】アプリの規模がとても小さく、処理内容も少ないのでちゃんとした「設計書」の類は作成しません。<ユースケース>【前提】コンソール画面のATMとします。ユーザー認証は行いません。単純に金額を入金、引き出しができるものを作ります。部品を作る<部品候補>からクラスを2つ作成します。クラス名はアルファベットで作成する必要がある(全角の文字でも作成できますが、なんとなく嫌なので。)MainBankクラス(メインメソッドを持つ)Calcurationクラス(引出し、入金を管理する)上のように名前をつけます。このように「役割分担」をしてやれば、いざ修正するときにどちらかのクラスの一部を修正してやれば、デグレート(修正したらおかしな事になる)する事もないように作ることができます。ここのポイントとしては、書く処理の依存度をなるべく低くしてやることです。依存度が高いと下のようなコードになります。・}入力を受けたあとに入金処理を同じクラスの中に書き始めると、結局のところは全部の処理をMainBankクラスに書くことになります。ソースを読む時は全部読まないといけないし、修正するときも、あちこち直さなくてはいけません。残業パラダイス必至のコードです。平和のためにこのような作成方法はやめましょう。依存度を下げるためにクラスを複数作成し、役割分担をしてやります。今回のコンソールアプリを作るのには以下のような2つの処理が必要です。し処理のそれぞれを行う。ポイント受付部分は共通なので、MainBankで行う入金処理、引出し処理は独立させることができるので分割するそんなわけでMainBankクラスCalcurationクラス上記のクラスを作成することにしました。MainBankクラスアプリケーションの起動とコーダー銀行の受付処理を行います。処理の詳細に関しては、以下の通りになります。コーダー銀行の受付文言をコンソールに表示デフォルトの預金金額¥1000-を表示する入金(in)、引出し(out)の判定を行い、処理終了する時は「bye」の入力で処理を終了するそのほかの入力はエラーメッセージを表示してサイド入力を促す表示を行うCalcurationクラス入金、引出し処理を担当するクラスです。このクラスには預金額を管理するためのフィールド変数が必要になります。入金処理、引出し処理では以下のような処理が必要になります。入金・引出し処理を行う旨を表示する。それぞれの処理を行った後の預金額を表示する。受付〜各処理への状態が変化していることをプログラム的に区別する必要がある。上の3番に関して、「プログラム的に〜」と記載している部分は「状態」を管理することにより処理クラスを変更、管理しやすいのです。この設計手法に関してはGOFのデザインパターンなどを読んでみるととても参考になります。良いデザイン(設計)をできるようになると、色々と楽ができます。