PHPによるデザインパターン入門 - デザインパターンを使うデメリット
このエントリは、Do You PHP?(www.doyouphp.jp)で公開していたコンテンツを移行/加筆/修正したものです。公開の経緯はこちらをどうぞ。目次はこちらです。
ここまでデザインパターンを紹介してきて、「何だ。良いことずくめじゃないか」と感じられたのでないかと思います。しかし、デザインパターンは、万能薬でも銀の弾丸でもありません。やはり、デザインパターンにもデメリットはあります。
デザインパターンのデメリットについても、簡単に整理しておきます。
開発者どうしがデザインパターンを知らなければ、コミュニケーションが成立しない
コミュニケーションについても先のメリットに挙げましたが、当然コミュニケーションをとる相手もデザインパターンを知っている必要があります。そうでないと、一方通行な会話になってしまいます。
パターンのクラス図をそのまま適用しようとする
デザインパターンを学習している、もしくは一通り学習してから問題となる点です。
実践する際、UMLで描かれたクラス図をそのまま適用しようとしてしまいがちです。たとえば、Factory Methodパターンのクラス図があるとしましょう。
この場合ですと、「Creatorクラスはinterfaceにしてはいけない」とか「ProductクラスやConcreteCreatorクラスには、他のメソッドを追加してはいけない」といったものです。
デザインパターンは、法律や規則ではありません。問題解決のためのノウハウを提供しているものです。ひょっとすると、クラス図そのままで適用できる場面もあるかもしれません。しかし、ほとんどの場合はクラス図そのままではなく、何らかのアレンジを加えた状態で適用することがほとんどと思います。先のFactory Methodパターンの場合、Creatorクラスをinterfaceや抽象クラスで実装したりすることも問題ありません。当然、具象クラスで実装することもあるでしょう。また、Productクラスに多くのメソッドが用意されていることもあります。
このことが足かせになり、誤った適用を強いてしまう可能性があります。
無理にでもパターンを適用しようとする
これも学習中、学習後に問題となる点です。
人は新しく覚えた知識を使いたがります。このため、デザインパターンを無理やりでも適用しようとする事があります。「金づちを持つとすべて釘に見える」と言ったコトバもありますね。
先の例でも挙げましたが、デザインパターンは、問題解決のためのノウハウを提供しているものです。あくまで「問題を解決する」のですから、無理やり適用しても正しい使い方をしない限り、デザインパターンのメリットを教授することはできません。
