ゆーたんのつぶやき

株式会社ノークリサーチにてIT関連のシニアアナリストとして活動しています。

デザインパターンへの取り組み



デザインパターンは雑誌などでも定期的に取り上げられるメジャーな話題の一つですね。
特にJ2EEでのシステム開発においては今や必須のスキルと考えても良いでしょう。
ですが、デザインパターンの利用を始めて導入したり、人に教えたりする時には注意が
必要だと思います。ボクは以下の2点に気をつけるようにしています。


1. 推奨されるデザインパターンは開発言語や開発プラットフォームの進化と共に変化する


 デザインパターンというのは実装段階に関連するソフトウエアパターンです。ですので
 ある程度実装技術に依存するものと考えています。例えばEJB1.1におけるEntityBean
 の利用において定石とされていたことが、EJB2.0においてはアンチパターン扱いになっ
 ていたりします。(この例では明確に名前のついたデザインパターンがあったわけでは
 ないですが) 一度覚えたデザインパターンを実装技術の進化を無視して使い続けると
 あっという間にアンチパターン化してしまいます。ですので、デザインパターンを勉強
 するときにはその下敷きになっている実装技術の現状とセットで把握しておく必要があ
 るように思います。


2. デザインパターンを最初に導入するタイミングはリファクタリングの段階が適している


 初めてデザインパターンを覚えた人にいきなり設計段階からデザインパターンを使わせ
 ようとするのは避けた方が良いように感じます。覚えたパターンのどれに当てはまるか?
 とか自分の設計がアンチパターンに該当していないか?といったことばかり気になって
 しまって、肝心の要件定義の実装がおろそかになってしまう危険性があります。初めて
 導入するのであればリファクタリングの段階がベストではないでしょうか。一通り実装
 したコードを眺めてみて、それを改変する場面を想定したときに多くの手間がかかって
 しまうとすれば、それはデザインパターン的な検討を加える価値があります。自分が書
 いたコードに当てはめて考えれば理解もしやすいですし、1.のポイントも抑えやすくな
 ります。


コードの再利用性だけでなく、実行時のパフォーマンスなども考慮して有効なパターンを
チーム内で蓄積しておき、設計段階から「この機能はこれくらいのデータ容量になること
が予想されるから、この要求レスポンスタイムを実現するためにこのパターン実装で行こ
う!」みたいな会話がチーム内で日常的にできるようになったらいいなぁと思います。