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