🔨伽藍とFacade（ファサード）パターン モジュール化とサブシステムとの違い encode/build/compile などなど まとめるファサード
ほとんど味のしないガム、モジュール化と何が違うのか、読み方がへんなぶん不気味
ファサードパターンと一般的なモジュール化の主な違いは目的と役割にあります。
目的:
ファサードパターン: システムのサブシステム間の相互作用を単純化するための統一されたインターフェイスを提供します。これにより、外部からサブシステムをより簡単に使用できるようになります。
一般的なモジュール化: システムを独立した部分（モジュール）に分割することで、再利用性、保守性、理解性を向上させる目的があります。
役割:
ファサードパターン: 複数のサブシステムのインターフェイスをまとめて、それらのサブシステムへのアクセスを単純化します。一般的には、クライアントとサブシステム間の複雑な依存関係を減少させ、直接的なアクセスを防ぐために使用されます。
一般的なモジュール化: システムを機能的または論理的な単位に分割します。各モジュールは特定の機能や責任を持ち、そのモジュール内でのみ重要な詳細をカプセル化します。
ファサードパターンは複雑さを隠蔽し、シンプルなインターフェイスを提供するためのものであり、一般的なモジュール化はソフトウェアの構造と組織を改善するためのものです。
クラスが一個あって、とりまとめしてくれるようなパブリックのメソッドの中に、サブクラスと呼べるようなクラスや機能がごちゃごちゃと入っていれば、いつのまにかそれは｣ファザード」になる
複雑に入り組んだクラスの関係を、Facadeという入り口のようなものをこさえてみるという考え方。
牛耳る観点ではmediatorやobserberに似てる。
「牛耳を執る」、「牛耳る」ことは諸侯たちの夢でした。誰もがこの集まりで最初に牛耳を手にとりたい、その場の一番になりたがりました。こうしてこの場はときに争いの場にもなりました。
牛耳られ仕切られた集団のことをここでは「サブシステム」と呼んでいる。解説ではコンパイラの例を持ち出し、もしこの先の人生でファサードとコンパイラの例をとりだしてくるひとがいたら、あ、これだ、と察しましょ。
例えば、アプリケーションがコンパイラ・サブシステムにアクセスできるプログラミング環境を考えてみましょう。このサブシステムには、コンパイラを実装する Scanner、Parser、ProgramNode、BytecodeStream、ProgramNodeBuilder などのクラスが含まれています。特殊なアプリケーションでは、これらのクラスに直接アクセスする必要がある場合があります。
しかし、一般的にコンパイラのクライアントの多くは、解析やコード生成などの詳細は気にせず、単にコードをコンパイルしたいだけです。しかし、コンパイラ・サブシステムの強力でありながら低レベルのインターフェイスは、彼らのタスクを複雑にするだけです。
仕事の取りまとめとして、ファサードを設ける。バッチプログラムを書いて作業をまとめるとか、そういうことを言っている。
最も単純なパターン
例えば、猫と一緒に短い面白い動画をソーシャルメディアにアップロードするアプリは、潜在的にプロの動画変換ライブラリを使用することができます。しかし、本当に必要なのは、単一のメソッド encode(filename, format) を持つクラスです。このようなクラスを作成し、動画変換ライブラリと接続すると、最初のファサードができあがります。
パターンと呼んでいいのかというぐらい単純
実際のクラス図も見てみようかという気持ちになってくる。
ほらカンタン。モジュールとかは任意だ。ライブラリの利用者はファサード以外何も見えない、という所がポイント。
こちらは委譲（deligation)のコンセプトとして、単体でも使われるかもしれない機能群をfacadeが口利きとなってすべてを取り締まる、というアプローチで、リファクタリングにもプロトタイピングにも使えるが、名前を付けるほどのことかという気持もする。
プロトタイピングやモックの目的でファサードという概念をうまく扱っているのはlarabelだ。
こちらの例では銀行を模しているが、classを覚えたら取りまとめしたいと考えるのは人情で、サンプルを見て考えるよりも、「気づいたらそこにファサード」。
単純仲間のシングルトン
一緒に使う場合シングルファサートンというペットントンみたいな名前になる
お願い致します