第2回 オブジェクト指向、本当に分かってる？

http://jibun.atmarkit.co.jp/lskill01/rensai/imajava02/imajava01.html
ふむ．全然分かってないようだね．

いつものように『UMLモデラーによるオブジェクト指向』の臭いがプンプンする．

このプログラムは、前回も説明したとおり自動販売機（Vending）とその利用者（User）をシミュレートしたものです。

おや？自動販売機は"vending machine"じゃないのかな？vendingと無意味に省略するのは可読性が損なわれ，開発者を混乱させるだけなので好ましくない．*1

クラスを作成しておくことによって、保守性も向上します。

OOPは保守性を上げるけれど，クラスだけを切り出しても意味はないよ．

例えば、自動販売機が故障したときのことを考えてみてください。故障個所を探す際に、設計図があればその場所を的確に把握することができ、ほかの機能に影響を与えずに修理（修正）することができるはずです。つまり、クラスがあることによってメンテナンスや仕様変更が容易になるのです。

違うな．そういう論理からすると「『プログラム』という設計図があるからソフトウエアは常に変更が容易に行える」ということになる．しかし現実はそんなに甘くはない．OOPの柔軟性はそれとは別次元の話だ．

クラスを作成しておく最大のメリットは、再利用性（汎用性）です。

OOPと再利用性に深い関わりがあるのも事実だが．

自動販売機クラスに定義した「自動販売機」というクラス名や「商品名」などの属性名は、非常にあいまいで抽象的です。つまり、このクラスからは「ジュースの自動販売機」や「タバコの自動販売機」など、「自動販売機」と名の付くものなら何でも生成できる可能性があるのです。

「可能性がある」かもしれないが実用性は０．いったい何年前の『オブジェクト指向』の話をしているんだろう．ここで出ている例は，いわゆる『差分プログラミング』の話だが，差分プログラミングが幅を利かせたのは1980年代後半くらいまでかな．

継承による拡張は決して万能ではない．詳細はEffectiveJava，項目15「継承のために設計および文書化する，でなければ継承を禁止する．」などを参照のこと．

Effective Java プログラミング言語ガイド

オブジェクト指向における再利用のためのデザインパターン

クラスの段階では意図的に抽象的に定義し、オブジェクトを生成する際に属性の値を決定するような仕組みは、非常に合理的だといえます。
オブジェクトの共通点を見いだして、その共通項目を定義した抽象的なクラスこそ、汎用性が高く使い回しの利くものになるのです。

こういう曖昧さはOOPの特徴ではなく，この『設計者』の初歩的且つ致命的なミス．OOPというのはもっと厳密なものです．絶対に抽象的に定義してはいけません．

あとは面倒なので省略．

*1:Vendingクラスだと「売り歩く」という行為そのもののオブジェクトだと見なされ，名前からは自動販売機クラスだとは予想できない．