定期的にSNS等で話題になる、オブジェクト指向。オブジェクト指向は今となっては古いみたいな意見もあって、どちらかというと批判的な意見も多いように感じます。
オブジェクト指向と一口に言っても、人によって何のことを指してるか微妙に違うと思うし、そこまで厳密な定義は無いかなとは感じます。とはいえ、定義が無いと論じるにあたってやはりふわふわしてしまう部分はあるので、一旦ここでは以下の記事にある、
オブジェクト指向はデータと操作手順を一体化（カプセル化）し、外部には処理の依頼方法（インターフェース）のみが公開されるため、ある箇所の変更が外部に与える影響を小さくすることができる。チームでのソフトウェア開発で分担などが行いやすく、大規模開発に向いていると言われる。適切に設計されたコードは他のプログラムで再利用しやすいため、似たような機能を重複して開発することを避け、開発の効率化を促すとされる。
ような設計や実装の手法を、オブジェクト指向とします。
では、オブジェクト指向を導入すると、何が嬉しいのかというと、以下の記事にあるような、
オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。
が挙げられると思います。ただ、分析段階で詳細に定義したクラス設計が、そのまま実装で使えるかというとそうでもない感じはして
結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。
というのはそんな感じはします。
従来オブジェクト指向が主に対象としてたのは、ウォーターフォールでいう詳細設計部分な感じがしていて、ドメイン的な意味合いよりは、実装をしっかり行えるような意図で導入されていた気はします。ただDDDの認知度がそれなりに広がっていくにつれて、詳細設計や実装よりも、もう一段階抽象的なドメインの重要性が上がってきた感はあります。
そうなると、詳細にクラスを設計できる仕組みの重要性が、下がってくるのではと思います。きっちりウォーターフォールをやるような現場でなければ、詳細設計書を作成することが少なくなってることも影響はしているでしょう。アジャイルに近いやり方の現場であれば、詳細設計書を作成することよりも、ドメインの認識をいかに一致させるかが重要視されてくる気はします。以下の記事で述べられてるような、
"それが何であり何でないか"それこそが重要である。設計的な文脈で言えば高凝集であると言えます。そして、高凝集であれば、インタフェースで抽象化せずとも変更に強いのです。これはアジャイル開発という歴史的な学習が教えてくれました。
抽象化は、もはや関心毎ではありません。再利用性が必要になったら、ポリモーフィズムを利用すればよい程度のもの。
という考え方が、広がってきているのかなとは思います。この高凝集を実現するにあたって、ごりごりにオブジェクト指向の機能を使い倒す必要性が、薄くなってきたようには感じます。
とは言え、DDDやアジャイルの考え方に至るまでの過程で、オブジェクト指向が果たした役割は大きいと考えています。実装対象がどのようなドメインで、どのような「もの」であるのか、そのような思考を掘り下げるきっかけになった考え方と思います。おそらく今後は、詳細設計書が書かれることは少なくなってくるかなと感じますし、その時には実装者がコードでいかにシステムの対象を表現するか、そういった設計スキルが求められてくるかなと思います。
