191.オブジェクト指向はコーディング技術です
初回：2021/12/08
P子「みんな知ってる事でしょ」（※1）
そうは言っても、入門書などで説明している例題は、オブジェクト指向の特徴は説明しても、それをどのように使いこなせばよいかという話は、あまりされていませんから、勘違いしたままって人も、案外多いのかもしれません。
ただし、以下の説明は、Javaに限定し、かつ、私個人の意見なので、正解があるとかないとかではなく、そういう考え方もあるんだな～という程度にお考え下さい。
P子「始める前に言い訳しておくのね」
1.普通のオブジェクト指向入門
オブジェクト指向の入門書では、その特徴の説明から入ると思います。
・継承
・多態性（ポリモーフィズム）
・カプセル化
・データと処理をパッケージ
・モノをオブジェクトとして定義
委譲とか、抽象化とかの話も出てくるかもしれませんが、本質的にはオブジェクト指向に特化した考え方ではないと思います。ただし、オブジェクト指向を解説する場合の重要な概念であることは確かです。
例題として、よく使われるパターンを上げてみます。
・動物クラスを継承して、犬クラス、猫クラスを作る（is-a関係）
・車クラスには、エンジンオブジェクトを包含する（has-a関係）
P子「つまり、包含したオブジェクトに処理を委譲するのね」
現実世界の『オブジェクト』をモノとして定義することで、プログラミングするんだなと理解することになります。
では、実在するペットショップや、自動車会社が、動物クラスとか車クラスとかを作って販売管理システムや生産管理システムを構築するのかというと、そんなことはありません。業務システムでは必須のデータベース（リレーショナルデータベース）とオブジェクト指向って、相性が悪いと思っています。
P子「そのための、O/Rマッピングじゃないの？」
そんなことをしないと使えないということ自体が、相性が良くない証拠です。
2.コーディング技術としてのオブジェクト指向入門
オブジェクト指向言語は、Javaを初め現在のプログラミングにおいては、ほぼ必須の考えです。リレーショナルデータベースは業務システムにおいては必須の技術です。では、これらの相性の悪い技術を使いこなす必要がありますが、データベースは基幹系システムとして長期間にわたって使用しますので、オブジェクト指向の方を合わせる方が楽そうです。
P子「合わせるって、どういう事？」
オブジェクト指向の高尚な『概念』を無視して、利用できる所だけを『良いとこ取り』するという事です。つまり、それがコーディング技術としてオブジェクト指向言語を利用するという考え方です。
具体例に入りましょう。
・初めに定義するのは、インターフェース
ここには、publicメソッドのみ定義するので、公開前提となる。
・次に、インターフェースを継承した末端のクラスを定義する。
末端クラスは、インターフェースで継承したメソッド以外は、private にする。
・末端クラスは、基本的にはイミュータブルにする。
状態を持たないので、マルチタスクでも安全に使える。
・末端のクラスのオブジェクトを生成するためのファクトリメソッドを用意する。
多態性を活用するには、インターフェースのインスタンスを生成する。
オブジェクトを、直接 new で生成しない。
・末端のクラスで共通の実装を、abstractクラスを継承して共通化する。
is-a関係というより、単なる実装の共通化に継承を利用する。
・共通実装のうち、状態を持たない処理は、ユーティリティークラスにまとめ
staticメソッドとして使用する。
委譲というより共通関数呼び出しの様な使い方をする。
例えば、オブジェクト指向の特徴を無視して、すべて、staticメソッドのみでシステムを構築しても、それが最善であるなら、構わないという事です。
3.データベース設計を優先する
ペットショップの販売管理システムを構築する時に、犬クラスとか猫クラスは作りません。データベースの項目に犬、猫などの種類カラムを用意したり、誕生日、オス、メスの区別、血統書や予防接種の有無や販売単価などを準備するでしょう。
P子「予防接種は複数、何回も行うから、別テーブルで定義するのね」
テーブル設計に合わせてクラス設計すると、結構使い勝手が悪くなります。すると、全体的に見通しが悪いコーディングになります。つまり、保守が難しくなり、業務の変更に対応しにくくなります。本来、オブジェクト指向は、設計変更に強く、保守しやすいコーディングを目標にしているのに、本末転倒になります。
それなら、初めから業務の種別や業態に依存しない、単純にデータベースの行と列を持ったオブジェクトを用意した方が業務の変更や保守に強いコーディングができるという事です。
また、一覧表示の画面から、行や列のデータを更新したり、リンクを張ったり、表示形式を変更したりする機能を、多態性で実現すれば、必要都度新しいクラスを追加し、キーワードで生成（つまりファクトリメソッド経由で生成）すれば、拡張性も確保できます。
オブジェクト指向の言語を使うから、業務システムをオブジェクトとして設計する必要はないという事です。
難しい機能を使っていたり、複雑なクラス設計を行っても、保守する人たちが判らなければ、保守できませんし、改造・改善活動もできません。
今であれば、普通の技術者であれば、ある程度のオブジェクト指向の理解は可能でしょう。なので、すべてstaticメソッドで設計する必要はありませんが、不必要にデザインパターンごりごりなシステム設計がされていると、普通の技術者では保守できないでしょう。このあたりは、落としどころというか、各社の事情によると思いますので、一般論で正解はないと思っています。
なので、各社で好きに実装すればよいと思います。
P子「最後は丸投げね」
ほな、さいなら
======= <<注釈>>=======
※1 P子「みんな知ってる事でしょ」
P子とは、私があこがれているツンデレPythonの仮想女性の心の声です。