デザインパターンの落とし穴

デザインパターンカタログは汎用性を考慮した構造で記述されているので実際に適用するときにはオーバースペックなことがままある。
それを現実にあわせた適切な形に変形あるいは省略するスキルはデザインパターンを使用する初学者には難しいことが多い。　結果としてシンプルに作る目的でデザインパターンを適用したのにもかかわらず、かえって複雑でわかりにくくなってしまうことがある。

例えば、他システムとの通信のレイヤーとアプリ側のレイヤーのやりとり、でオブザーバーパターンをつかって、不定期なエラー通知をアプリ側に行う場合。

オブザーバーパターンのカタログの構造では、サブジェクトが変更されたらばオブザーバーに「変わったよ」っていうの通知して、オブザーバーはその通知をきっかけにサブジェクトの必要なデータを取く。

不定期エラー通知にこれをそのまま適用すると、なんらかのエラーが起こったという通知を出したあとにそのエラー内容をとりに行くことになる。
この場合の問題はエラー通知があってから、データを取りにいく間に他のエラーがあったらデータが上書きされてしまうことになる点。

この場合の適切な変形は、オブザーバーから取りにいくことをやめて、「変わったよ」の通知の引数でデータを渡してしまうことである。

オブザーバーパターンのカタログとしての汎用性はオブザーバー側の都合で必要なサブジェクトのデータをとりだすことにある。

今回のエラー通知の場合は、オブザーバーの都合で必要なデータの種類が変わることはないので、通知するときにデータを渡してしまうのが手っ取り早い。

デザインパターンを適用するときはオブジェクト間のそれぞれのインタラクションが何のために、やっているのかのその理由を理解したうえで適用しないと余計な実装をしていたずらに複雑にしてしまうということ。