8.1 分解がすべて
わかりやすくするために、優れた記事「オブジェクト指向システムの分離」からの図で、これから説明する主な点を示しています。
アプリケーション アーキテクチャの設計は簡単だとまだ思っていますか?
8.2 インターフェース、実装の隠蔽
システムの結合を減らすための主な原理は、OOP の原理と、その背後にあるカプセル化 + 抽象化 + ポリモーフィズムの原理です。
それが理由です：
- モジュールは相互に「ブラック ボックス」である必要があります (カプセル化)。これは、あるモジュールが別のモジュールに「登って」、その内部構造について何も知ってはならないことを意味します。あるサブシステム内のオブジェクトは、別のサブシステム内のオブジェクトに直接アクセスしないでください。
- モジュール/サブシステムは、インターフェイス(つまり、実装の詳細に依存しない抽象化)を通じてのみ相互に対話する必要があります。したがって、各モジュールには、他のモジュールと対話するための明確に定義されたインターフェイスが必要です。
「ブラック ボックス」(カプセル化) の原理により、各サブシステムの構造を他のサブシステムから独立して考慮することができます。モジュールは「ブラックボックス」であり、比較的自由に変更できます。問題は、異なるモジュール (またはモジュールと環境) の接合部でのみ発生する可能性があります。
そして、この対話は最も一般的な (抽象的な) 形式、つまりインターフェイスの形式で記述されなければなりません。この場合、コードはインターフェイス コントラクトに準拠するどの実装でも同様に機能します。ポリモーフィズムと呼ばれる、統一されたインターフェイスを通じてさまざまな実装 (モジュールまたはオブジェクト) を操作できるこの機能です。
これが、サーブレットがインターフェイスである理由です。Web コンテナはサーブレットについて何も知りません。Web コンテナにとって、これらはサーブレット インターフェイスを実装するいくつかのオブジェクトであり、それだけです。サーブレットはコンテナの構造についてもある程度知っています。サーブレット インターフェイスは、Java Web アプリケーションを世界に普及させるために必要な契約、標準、最小限の対話です。
時々誤解されているように、ポリモーフィズムはメソッドのオーバーライドではなく、まず第一に、同じインターフェイス、または「1 つのインターフェイス、多数の実装」を持つモジュール/オブジェクトの互換性です。ポリモーフィズムを実装するために、継承メカニズムはまったく必要ありません。一般に継承は可能な限り避けるべきであるため、これを理解することが重要です。
インターフェイスとポリモーフィズムのおかげで、すでに書かれたものを変更せずにコードを変更および拡張できる機能 (オープン-クローズ原則) が実現されます。
モジュールの相互作用がインターフェイスの形式のみで記述され、特定の実装に関連付けられていない限り、システムにとって、あるモジュールを同じインターフェイスを実装する別のモジュールに完全に「苦痛なく」置き換える機会が与えられます。新しいものを追加して機能を拡張します。
これは LEGO コンストラクターのようなものです。インターフェイスは対話を標準化し、適切なコネクタを持つモジュールを接続できる一種のコネクタとして機能します。
設計者の柔軟性は、あるモジュールや部品を同じコネクタ (同じインターフェース) を備えた別のモジュールや部品と簡単に交換できるだけでなく、好きなだけ新しい部品を追加できる (同時に既存の部品を追加できる) ことによって保証されます。部品はいかなる形でも変更または変更されません)。
インターフェイスを使用すると、各サブシステムを全体として考慮し、その内部構造を無視して、より単純なシステムを構築できます。これらにより、モジュールが相互作用すると同時に、互いの内部構造について何も知ることができないため、疎結合の基礎である最小限の知識の原則が完全に実装されます。
インターフェースがより一般的/抽象的に定義され、対話に課す制限が少なくなるほど、システムはより柔軟になります。ここから、実際には SOLID のもう 1 つの原則、つまり「厚いインターフェイス」に対抗するインターフェイス分離原則に従います。
同氏は、大きくてかさばるインターフェイスをより小さく、より具体的なインターフェイスに分割して、小さなインターフェイス (依存モジュール) のクライアントが操作する必要があるメソッドのみを認識できるようにする必要があると述べています。
この原則は次のように定式化されます。「クライアントは、自分が使用していないメソッドに依存すべきではない（メソッドに注意する）」または「多くの特殊なインターフェイスは、1 つの汎用インターフェイスよりも優れています」。
弱い接続性は、モジュールの相互作用や依存関係が、モジュールの内部構造や構造に関する知識を使用せずに、インターフェイス、つまり抽象化のみを使用して記述された場合にのみ提供され、実際にカプセル化が実装されていることがわかります。さらに、さまざまな実装を追加および使用することによって、つまりポリモーフィズムにより、システムの動作を拡張/変更することができます。はい、私たちは再び OOP (カプセル化、抽象化、ポリモーフィズム) に行き着きました。
8.3 ファサード: モジュールインターフェース
ここで経験豊富なプログラマーは、設計が対応するインターフェイスを実装するオブジェクトのレベルではなく、モジュールのレベルである場合、モジュール インターフェイスの実装は何でしょうか?と尋ねます。
答え: デザイン パターンの言語で言えば、特別なオブジェクトがモジュール インターフェイス - Facadeの実装を担うことができます。Gateway サフィックスを含むオブジェクト (MobileApiGateway など) のメソッドを呼び出している場合、それはファサードである可能性が高くなります。
ファサードは、特定のサブシステムを操作するための高レベルの一連の操作を蓄積するインターフェイス オブジェクトであり、その内部構造とその背後にある実際の複雑さを隠します。サブシステム実装の変更に対する保護を提供します。単一のエントリ ポイントとして機能します。「ファサードをキックすると、必要なものを取得するためにこのサブシステムで誰をキックする必要があるかを彼は知っています。」
モジュールの設計時にインターフェイスの概念を使用し、モジュールを分離できるようにする最も重要な設計パターンの 1 つである「ファサード」を紹介しました。
さらに、「Facade」では、通常のオブジェクトと同じようにモジュールを操作でき、クラスの設計で使用されるすべての便利な原則とテクニックをモジュールの設計時に適用できます。
注: ほとんどのプログラマはクラス (オブジェクト) を設計する際にインターフェイスの重要性を理解していますが、多くの人はモジュール レベルでもインターフェイスを使用するというアイデアを発見しているようです。
GO TO FULL VERSION