クラスの中のクラス、インナークラスを主たるクラスの中に定義する事で不要なケアレスミスを防ぐ事ができる。
AndroidStudioで、作成アプリに似たテンプレートを選択し、それを改造して最終アプリを完成させる。
例えば、データの塊を管理するPlaceItemHolderクラス中にデータの構成を定義するPlaceItemクラスを定義する。
このシチュエーションで、学ぶことが多数ある。リスキリングではないけれど、思い出している？なにを？
相当昔の苦い思い出。テストでは、コンパイルエラーがでなかったのに、テスト用ロードモジュールをコンパイルしたら、
何故か？コンパイルエラーが出てしまった。大騒ぎになった．．．（ホスト開発）
原因は自分のソースがコールしているサブルーチンのスペックが変更されていた。
変更されたサブルーチンのオブジェクトが古いままでのリンケージ（分かるかな？）ではOKだったのだ！
それからは、（そして当たり前になったが）ロードモジュールを一か所に集めてコンパイルする事になった。
これで新旧のオブジェクトが混じることなくなったが、全てをコンパイルするので実時間が必要になった。
まぁ当時は定時が午後１０時（ブラックである）だったので障害にはならなかったが。
時代は下って、PCで開発を行う環境が当たり前になって、同じ新旧が原因で実行時エラーが起こる事が多くなった。
解決策は、やはり一か所に集めたソースコードをPCに持ってきて全コンパイルではあった。
（Cでの開発）
時間がかかるのが、今度は、障害になってきた。PCの能力の低かった事が本当の？原因？？
更に時代は過ぎて、Javaでは、インタフェースを変えずに中身（機能）を変えることが常識となった。
呼んでいる（メッセージを送る）相手が最新なのかどうかが問題になったね。そこで、コンパイル単位を決め、
ファイルに複数クラスを定義し、同時にコンパイルする事で新旧の矛盾が起こらないようにした。
PC主体で分散開発をする場合、責任範囲毎にコンパイル単位を決めるが、ファイルを構成するクラス数が
多くなり、取り扱いを慎重にしなければいけなくなった。ソース管理も必要になった。
数多くのソース管理ソフトが出てきたね。これはケアレスミスである「取り違え」を防ぐ効果がある。
USでは（私の環境以外？）では常識なのか、Googleでは常識なのか？
学ぶ事が多くて、咀嚼が終わるまで先に進めません。
