共通関数継承のデメリットを考える

id:katzchang さんのエントリに触発されて、おいらも共通関数継承のデメリットを考えてみました。
共通関数継承のデメリットを説明せよ - @katzchang.contexts

共通関数継承のデメリット

• 低凝集度、密結合のクラスができあがる。その結果、変更に弱く、再利用性が低いクラスとなる。

• 単一継承しかできない言語の場合、別の機能を拡張したり、フレームワークを活用しようとしたときに新たに継承を行うことが困難になる。

• 継承に関するルールがない場合、各開発者が好き勝手に既存のクラスを継承して機能を拡張しようとする。その結果、複雑で一貫性のないクラス階層ができあがってしまう。

おいらが考える大きなデメリットはこんなところですかね〜？
一番大きなデメリットは最初の凝集度や結合度の問題かな。

テスト容易性が落ちる、という意見もあるようですが、これは継承が直接もたらすデメリットではなく、何らかのフレームワークがないとコードを実行できない場合に発生する問題であるような気がします。

共通関数継承から疑われる根本的な設計上の問題について

そもそも共通関数継承が登場するということはおそらくオブジェクト指向分析やオブジェクト指向設計を採用せずに開発が進んでいる可能性が高いです。
きっとクラスをモジュールやライブラリのような機能の集合体だと勘違いしている人が設計していると思われます。

となると、オブジェクト指向における設計の原則*1は全く守られない、というか発想のベースが根本的に異なるので、まず最初から作り直さないと原則も適用できません。

共通関数継承を改善するには共通で使われる機能を別クラスに切り出せば、結合度が下がり、再利用性も向上しますが、おそらくそれ以上に「もっとまずい何か」潜んでいるでしょうね。

なぜアンチパターンとしてのインパクトに欠けるのか

ところでなぜこの問題のインパクトが弱いのか、相手を説得するための決定打を出しにくいのか、という点についても考えてみました。
おいらが考えた理由は

「共通関数継承のデメリットは主に変更容易性や再利用性に関連するものであり、可読性や不具合とは直結しにくいから」

というものです。まあ、これはこれで何かインパクトに欠ける気もしますけどね。。。

さらに、問題を指摘した相手がオブジェクト指向設計に興味がなければ、「ふ〜ん、あっそう」で終わってしまいそう。
やっぱり決定打は出ないのかな〜？う〜ん。。。

参考文献

最後にこの手の話を議論する際に参考になりそうな書籍をいくつか挙げておきます。
このエントリを書く際にも参考にしました。

オブジェクト指向開発の落とし穴

正しく学ぶソフトウエア設計 ─オブジェクト指向分析/設計を根本から理解する (日経BPパソコンベストムック)

実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング)

こうした本で勉強して、分かりやすく変更に強いシステムを設計しましょう♪

*1:オブジェクト指向設計の原則については http://www.syboos.jp/sysdesign/category/20080607211127406.html とか http://ja.wikipedia.org/wiki/GRASP を参照