>>293の元設計の問題点(つづき２)
(2-1. Bridgeパターン・スパゲティ (クラスの過剰な分割によるOOモデルの崩壊))

　>>293のコード(及び>>304の補足コード)は､その字面の単純さにもかかわらず､
　挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)

　(1)挙動を読み取りにくくなる原因：
　　原因(1-1) データと処理の分離記述による、カプセル化の破壊。
　(2)保守性が悪い原因：
　　原因(2-1) カスタマイズ内容のハードコーディング。
　　　　 クラス選択の変更や、クラスの新規追加の度に、コード修正が必要になる。
　(2)前提条件の変化に対し柔軟性が低くなる原因：
　　原因(3-1) モデルの過剰な単純化により、現実世界の複雑な問題に適応できなくなる。

　以下では、その原因を探る。
　原因(1-1)データと処理の再分離による､カプセル化の破壊
　　　　オブジェクト指向では､データとその処理をカプセル化し、クラスを導入する事で
　　　　(1)データ操作の局所性
　　　　(2)外部操作インタフェースの限定、
　　　　(3)型システムによる安全性/信頼性の向上
　　　　が可能になり、それを利用してプログラムの信頼性/可読性/保守性の向上を図れる。

　　　　しかし>>293,>>304のコードでは、
　　　　データ(Hanzai及びﾊﾞﾘｴｰｼｮﾝ)と処理方法(〜Processor)を別々のクラスに分離記述した後、
　　　　関連するデータクラスと処理クラスを適切な方法で再カプセル化しなかったため、
　　　　オブジェクト指向のメリットが得られなくなっている。(非ＯＯ的コード)