オブジェクト指向の曖昧さ
「オブジェクト指向」への記事や書籍、感想は数多あるけど、実のところ雲のような概念。別の意味で、クラウドだなと。
そして、それゆえに、説明も評価もいろいろと錯綜している。ある意味、メタボでありFat Wordだなと思う。
「オブジェクト指向」という"言葉"は手法や観点を探す道標
一ついえるのは、オブジェクト指向そのものよりは、それで検索したときに、クラス、カプセル化、ポリモーフィズムとかいろいろなプログラム設計上の手法にふれることができる。
そういった意味で、「オブジェクト指向」という言葉そのものよりは、手法が大切で、その手法を探すための道標として「オブジェクト指向」という言葉は便利だと思う。
オブジェクト（対象）を中心に考える
言葉だけを読めば、「オブジェクト指向」だから、「Object：客体、対象」を中心に考えることかなと思う。逆に、「手続き指向」なら、処理を中心に考える。
プログラムにおいて、ソースを分ける、値を分ける、処理を分けるというのは設計の中心的な事柄になる。その時、字義通り、「Object：客体、対象」を中心にグループ化していくとたしかに、分けやすく、コードリーディングしやすかったり、メタボソース、ファットクラスを避けやすいように思う。
設計・概念上のオブジェクト、コーディング上のオブジェクト
前述した設計・概念ではなく、コーディング上では、オブジェクトは複数の値の集合、値と処理の集合であったりする。それをJavaやC++、C#みたいに、クラスで定義するのか、GoやRustみたいに構造体で定義するのかはいろいろあれど。
コーディング上のオブジェクトは何にでも適用できてしまうので、概念上の「Object：客体」をどう捉えるかに拠って、いろいろ表現できる。
たとえば、「ファイルを保存する」という処理がある。これを、「File.Saver」というクラスを作ってもいいし、「保存する機能」というところを客体にして、「Saving.File」、「Storage.File」とするのもありだと思う。
コーディング上からすれば、値や処理を集合させればオブジェクトになるが、設計や概念とは別物で、どのようにだって表現できてしまう。
指向・概念と手法を分けて考える
よく語られるオブジェクト指向の設計や手法は、このオブジェクトをうまく使う利用方法についてが書かれてて、それが概念と手法が混在してて、それが曖昧さを生んでいるんではないかなと思ったりする。
オブジェクト指向は万能ではなく得意な分野と不得な分野がある
オブジェクト指向はだめだという意見があるけど、それは、処理の流れなど手続き指向の方が向いているような場所でつかうとそうなるかもしれない。
設計手法は、使う場所を選ぶということで、オブジェクト指向が万能薬でもないし、逆に、だからといってオブジェクト指向が駄目だというわけでもない。