Facadeパターン

Facadeパターンは割と意識することは多いんですが、実際書くか、というとどうでしょう...。

Facadeパターンの中身が闇すぎて、Facadeパターンらしく包まれたAPIによって呼び出されているバッチ処理がこけたときに、画面を開いてうっ...となる気持ちがあります。

あの、~200行のメソッドを書かないで......。

まあ、書かずに毎回コンソール叩いてドやする事がいいことでも無いんですが......。

この要素の取得や装飾のためにはこの要素があることを事前に確認して...みたいなややこしいDOMの処理をViewのrenderXXX()でラップするくらいに留めて欲しい感じがあります。

まあ、可能な限りFacadeパターンを使わなくていいようなクラスを書きたいんで、Decoratorパターン(呼び出しの前後で、メソッドを適用前のAPIも使える)とかCompositeパターンとかその辺を扱えるようにしておきたい感じ...。

Facadeパターンは外部とのやり取りをするとき、APIを公開するときに、1回でスムーズに欲しいデータを取得させて上げられるか、みたいな所に留めたいのよ...。

他の箇所のコーディングのためにまとまって何回か扱う必要があるなら、実際には、積極的に包んでFacade, Facadeしていくけど... Facadeの闇を作らない努力もしたいな、なんて。

(途中で通信がこけた場合のエラーハンドリングがどうなっているかとか、途中でこけたらヤバい処理が含まれていない感じならFacadeいいんだけど、言い訳せずエラーハンドリングを考えていった方がいいのかな...とか、そういうことしてると闇な部分の作業がそういうことする人に集まってしまうのかな、とかもにょもにょ余計な事考えてしてしまう)

要するに単に長いメソッドと適切な順序でAPIを叩いてくメソッドの区別をして考えたくて、それはつまり、現実のプロジェクトではそもそもFacadeから利用する単品のAPIも整ってない場合が多くないですか。という話かも。。