⚠️注意：この記事には一般的なモノの考え方とはかけ離れたひねくれ思考が含まれています
※ この記事はプログラマー向けの内容なので、一般の方は理解不能になる怖れがあります
オブジェクト指向設計をすれば プログラムが読みやすくなる、という人がいます
これ、間違っていますよね？
読みやすいプログラム記述書
「読みやすさ」というのは人によって評価が変わる答えが一つではない評価軸です
例えば日本人の誰もが読みやすいプログラムというなら、みんな大好き Excel 方眼紙の日本語で書かれた詳細設計書が一番読みやすいプログラム記述になります
IT を知らない顧客のために SIer が用意した処理記述方法なので当たり前ですよね？
Excel 方眼紙の詳細設計書はオブジェクト指向設計でしょうか？
全然抽象化していないし、違いますよね？
優れたオブジェクト指向設計をしたってプログラムは読みやすくはなりません
プログラマー側が、自らの目線、評価軸からだけで読みやすくなったと思っているだけです
プログラム設計は何のため？
だとすれば、なぜプログラマーはオブジェクト指向設計のような、抽象的で理解しづらい設計をするようになったのか？
それは仕様変更を繰り返しても、可能な限り実装変更の影響範囲を小さく留めることで、より少ない手間で修正し、不具合の発生を防ぐためです
システム開発やプログラミングを、住宅建築と同じようなものととらえて、一度完成したら、基本修正することはまれと考えているような人がいます
実際はそうではなく、一度完成した後も、需要やユーザーの反応に合わせて細かく修正やアップデートをするのが普通であるし、そちらの方が商業的に成功しやすいです
身近な例なら、コンシューマーゲームとソーシャルゲームがわかりやすいかもしれません
ソーシャルゲームは頻繁にアップデートをして、次々とユーザーを惹きつけるキャラクターやコンテンツが追加されていくので、コンシューマーゲームよりも長期間売り上げを上げ続けて大きな商業的成功を収めやすいです
最近ではコンシューマゲームでも、ダウンロードコンテンツとして追加のアップデートを行う傾向があるくらい、完成後に修正を行っていくことが自然になってきたと思いませんか？
プログラムという電子的な設計行為を行うからこそ、住宅建築のような物理的な設計よりも、はるかに柔軟かつ頻繁に修正を行うことができ、それが強みになっているわけです
だからこそ、プログラミングの設計には、仕様変更を繰り返しても不具合を起こさずに素早く吸収する柔軟さが求められ、その目的でオブジェクト指向設計のような手法が編み出されたんです
優れた設計は継続的な仕様変更に耐えられる
仕様変更、すなわち人間の需要、要求の変化に追従する修正の影響範囲を「オブジェクト」という概念のまとまりでとらえ、局所化させることにより、上記のような柔軟さを持たせやすくなるから、プログラマーがオブジェクト指向設計をするようになりました
最初は「動物」という概念でオブジェクトを作り、共通の特徴で「移動する」みたいな機能を持たせていたところに、「猫」という「動物」が必要になった
「猫」は「動物」なので「移動する」機能は変更したくないが、「にゃー」と鳴く機能を追加したい⋯みたいな仕様変更が起こりがちだからというわけです
変更したい部分と変更したくない部分、共通にしたい部分と個別に差をつけたい部分、仕様変更の発生の仕方に合わせて、影響範囲のグルーピングを適切にコントロールするためなので、設計の目的は読みやすくするためではないはずです
このことを勘違いしている日本のプログラマーが多すぎる！
そして勘違いをしたまま、完成後はガチガチで融通が利かず、変更しにくいひどい設計をする SIer のシステムエンジニアが多すぎる！
どういうわけか、いわゆる「読みやすさ」のためではない設計、パフォーマンスチューニングや最適化といった領域は正しく認識できており、日本のプログラマーのレベルも高いです
ただ、こういった仕様変更に耐えるアーキテクチャ設計になると、海外のプログラマーに比べ日本のプログラマーのレベルが著しく低いような気がします
