10年くらいJavaのシステム開発に携わってきました。
何度かオブジェクト指向とは？という話を、現場で話したり、本を読んだり、ネットで調べたり。
そんな中、現場面接でオブジェクト指向の良い所は？と聞かれました。
その時は、？？ってなったので、改めて思考を整理して、言語化してみました。
私と同じように、現場経験が長いけど、オブジェクト指向とは？と改めて聞かれると、？？となる方。
そんな方の思考整理のキッカケになればと思います。
参考サイト
整理する前のオブジェクト指向とは？
現実世界の考え方、見え方、をプログラミングの世界にそのまま持ってきている。
それゆえに、オブジェクト指向で作られたプログラムは、直感的に分かり易い（＝現実世界と似ているから）
と思っていました。
でも、あれ？ほんとう？今まで見たプログラムってそうだった？
と自問自答した結果、別の結論に至りました。
整理後のオブジェクト指向とは？
参考サイトのお言葉をお借りします。
「オブジェクト指向では全体の機能を一枚岩ととらえずに，データと手続きを持った「オブジェクト」の集まりとしてとらえる」
これにつきます。
それゆえに、オブジェクト指向で作られたプログラムは、個々の部品の独立性が高いので、保守性や再利用性が高くなり、開発工数、改修工数が従来より少なくなり、生産性が上がるという結論に至っています。
「オブジェクト指向では全体の機能を一枚岩ととらえずに，データと手続きを持った「オブジェクト」の集まりとしてとらえる」
私の理解を付け加えると、
「データ」・・・ 属性
「手続き」・・・振る舞い
を持った「オブジェクト」が、「集まったなら出来ること」が、それが「機能」。
開発工数、改修工数が従来より少なくなり、生産性が上がるという結論
オブジェクトは、独立しています。独立性が大切。
開発工数を少なくできる（再利用性）
独立した「たろすけオブジェクト」は、A機能にも、B機能の集合にも参加できます。
それって、A機能を作る時に、「たろすけオブジェクト」を作れば、B機能を作るときに、改めて作らずに済む。
改修工数が少なくなる（保守性）
独立した「たろすけオブジェクト」は、A機能にも、B機能の集合にも参加しているので、
A機能、B機能に共通した「手続き」を直す場合、「たろすけオブジェクト」の1か所の修正で済む。
上記をベースに3大特徴を自分の言葉で整理すると
ポリモーフィズム
指示する側が楽チン。
具体的に言うと、「ユーザ管理画面を作ってほしー」って思った時に、
指示する相手が、「たろすけ」だろうが、「からすけ」だろうが「ユーザ管理画面を作ってください」って指示すれば、作ってくれるということ。
中身は、「たろすけ」と「からすけ」で、個性に富んだ「ユーザ管理画面」が出来ます。
更にいえば、「ものすけ」が出てきても、同じ指示で大丈夫です。
継承
共通の親分類にお任せ。
具体的に言うと、「たろすけ」と「からすけ」で同じ手続きは、「すけ分類」の「親」、「おやすけ」を作って、そこにお任せする。
という感じですかね。
これも良い所は、「ものすけ」が出てきても、その手続きを使えるということ。
カプセル化
指示する側は、具体的な作業の中身を知らなくてよい。
これは、システム開発現場では、丸投げに当たりそうなので、お勧めできませんが、プログラム開発においては楽チンです。
ポリモーフィズムで、お話した「ユーザ管理画面を作ってほしー」って思った時に、
指示する相手が、「たろすけ」だろうが、「からすけ」だろうが「ユーザ管理画面を作ってください」って指示すれば、作ってくれる。
指示する側は、作り方を知らなくても良い。
というお話。
あれ？結局、オブジェクト指向って何が良いの？
独立性が高いから、開発工数、改修工数が従来より少なくなり、生産性が上がる。
かな。
とはいえば、世の中には、銀の弾丸があるわけでは無いです。
あれば、みんな使っています（笑）
なので、全てにカッチリ当てはまるとは思っていません。
ただ、便利な手法の１つとして、捉える。
使える所で使う。
っていうのが、良いかと思います。
駄文
頭で整理できた！って思って、言語化すると、色々詰まりますｗ
言語化は大切ですねｗ