デザインパターンのプラクティス

CodeZine：DBの仕様変更に強いDataAccessMethodパターン（J2EE, デザインパターン, DAO, DataAccessMethod）より。

　DataAccessMethodパターンに限らずGoFやCJ2EEのようなデザインパターンやそれに伴うツールの導入時には開発プロセスあるいは構成管理のカスタマイズを前提とするべきです。デザインパターンは優良で再利用可能な『設計方式』ですが、その効果を最大限にするにはそのパターン特有の『プラクティス』を取り込む必要があります。

　例えばFacadeパターンでは「Facade担当者に特殊APIによる開発を任せる」というFacadeパターン特有のプラクティスがあります。TemplateMethodパターンでは「TemplateMethod担当者に複雑な機能、HookMethod担当者に単機能を担当させる」というTemplateMethodパターン特有のプラクティスがあります。こうしたプラクティスを適切に取り込めなければ、デザインパターン導入の効果を得られなくなるどころか導入により逆にプロジェクトを混乱させる事態になるかもしれません。

　開発プロセスを従来のままにデザインパターンのような高度なノウハウを導入すれば、副作用が発生するのは自明なのです。これを避けるには、プロジェクト早期にデザインパターン導入を受け入れるにはどのようにプロセスをカスタマイズすれば良いかを十分に検討しなければなりません。

ごもっとも。