関係ないが、パターンは非常に危険。

多くのパターンは名前しらなくても、無意識につかってる。
関数の中で他の関数を呼ぶ事に名称はないが、クラスの中で
他のクラスを所有している事に名前がついている。さてそれが
有益だろうか。

継承は非常に便利であるが、きれいに設計されていない限り、
読みにくく、クラスの相関が極めて複雑になり、設計全体が
破綻に導く可能性のある非常に危険なものでもある。熟練者
以外が迷った場合は大抵継承をしないやり方を選ぶべきだ。

また、オブジェクト指向は元来、生産性のために実行速度を
犠牲にした概念。スピードを損なわないように緻密に作らない
限り実行スピードは遅くなる。

パターンはといえば、そのようなオブジェクト指向の難点を
助長させる部分で非常に危険である。たとえば、技とすれば
Chain of Responsibilityはかっこいいが、実際に使うとなれば、
ロジックの流れの見にくさを考えると、使わないで切り抜けられる
なら、避けるべきロジック。単純なＩＦ文を使えばいいところに、
わざわざ複雑なロジックを組み込むようなものだ。

パターンはこの辺の実行パフォーマンスやメンテ性に対するリスク
を知り尽くしてる人が、自分がある程度の経験でしってるクラス周り
のロジックを整理するには有効である。だが、それ以外は弊害の方が
上回ることが多い。自分でクラスを１０個程度しか作った事がない
人がパターンを覚えることによって、スキルアップする分よりも、
優先順位偏りからくるリスクの方が大きい。

ＸＭＬパーシング技術のＳＡＸは継承を前提とした画期的設計に
なっているが、その設計に反対視する専門家は少なくない。