10年くらいJavaのシステム開発に携わってきました。
何度かオブジェクト指向とは？という話を、現場で話したり、本を読んだり、ネットで調べたり。

そんな中、現場面接でオブジェクト指向の良い所は？と聞かれました。
その時は、？？ってなったので、改めて思考を整理して、言語化してみました。

私と同じように、現場経験が長いけど、オブジェクト指向とは？と改めて聞かれると、？？となる方。
そんな方の思考整理のキッカケになればと思います。

参考サイト

整理する前のオブジェクト指向とは？

現実世界の考え方、見え方、をプログラミングの世界にそのまま持ってきている。
それゆえに、オブジェクト指向で作られたプログラムは、直感的に分かり易い（＝現実世界と似ているから）

と思っていました。

でも、あれ？ほんとう？今まで見たプログラムってそうだった？
と自問自答した結果、別の結論に至りました。

参考サイトのお言葉をお借りします。

「オブジェクト指向では全体の機能を一枚岩ととらえずに，データと手続きを持った「オブジェクト」の集まりとしてとらえる」

これにつきます。

それゆえに、オブジェクト指向で作られたプログラムは、個々の部品の独立性が高いので、保守性や再利用性が高くなり、開発工数、改修工数が従来より少なくなり、生産性が上がるという結論に至っています。

私の理解を付け加えると、
「データ」・・・属性
「手続き」・・・振る舞い
を持った「オブジェクト」が、「集まったなら出来ること」が、それが「機能」。

オブジェクトは、独立しています。独立性が大切。

独立した「たろすけオブジェクト」は、A機能にも、B機能の集合にも参加できます。
それって、A機能を作る時に、「たろすけオブジェクト」を作れば、B機能を作るときに、改めて作らずに済む。

独立した「たろすけオブジェクト」は、A機能にも、B機能の集合にも参加しているので、
A機能、B機能に共通した「手続き」を直す場合、「たろすけオブジェクト」の1か所の修正で済む。

指示する側が楽チン。

具体的に言うと、「ユーザ管理画面を作ってほしー」って思った時に、
指示する相手が、「たろすけ」だろうが、「からすけ」だろうが「ユーザ管理画面を作ってください」って指示すれば、作ってくれるということ。
中身は、「たろすけ」と「からすけ」で、個性に富んだ「ユーザ管理画面」が出来ます。

更にいえば、「ものすけ」が出てきても、同じ指示で大丈夫です。

共通の親分類にお任せ。

具体的に言うと、「たろすけ」と「からすけ」で同じ手続きは、「すけ分類」の「親」、「おやすけ」を作って、そこにお任せする。
という感じですかね。

これも良い所は、「ものすけ」が出てきても、その手続きを使えるということ。

指示する側は、具体的な作業の中身を知らなくてよい。
これは、システム開発現場では、丸投げに当たりそうなので、お勧めできませんが、プログラム開発においては楽チンです。

ポリモーフィズムで、お話した「ユーザ管理画面を作ってほしー」って思った時に、
指示する相手が、「たろすけ」だろうが、「からすけ」だろうが「ユーザ管理画面を作ってください」って指示すれば、作ってくれる。

指示する側は、作り方を知らなくても良い。

というお話。

独立性が高いから、開発工数、改修工数が従来より少なくなり、生産性が上がる。
かな。

とはいえば、世の中には、銀の弾丸があるわけでは無いです。
あれば、みんな使っています（笑）
なので、全てにカッチリ当てはまるとは思っていません。

ただ、便利な手法の１つとして、捉える。
使える所で使う。
っていうのが、良いかと思います。

頭で整理できた！って思って、言語化すると、色々詰まりますｗ
言語化は大切ですねｗ