システム作成とシステム使用を分ける。

public Service getService() {
    if (service == null) {
        service = new MyServiceImpl(...); 
    return service;
}

これは遅延初期化または遅延計算の方法である.実際に必要とされるときにオブジェクトを生成しないため、不要な負荷が発生せずnullポインタも返さないという利点があります.
しかし,getServiceメソッドはMyServiceImplジェネレータの買収に明示的に依存する.実行時ロジックでMyServiceImplを使用しないとコンパイルできません.
テストも問題です.通常のランタイムロジックでオブジェクト作成ロジックがブレンドされているため、すべてのランタイムパスをテストする必要があります.
最も重要なのは、MyServiceImplがすべての状況に適しているかどうか分かりません.

しゅだんかい

システム生成とシステム使用を分離する方法の1つは、生成されたすべてのコードをmainまたはmain呼び出しのモジュールに移行し、残りのシステムがすべてのオブジェクトを作成し、すべての依存項目に接続していると仮定することです.
すべての矢印はmainからアプリケーションを指します.つまり、アプリケーションはmainやオブジェクトの生成プロセスを全く知らない.

こうじょう

アプリケーションがオブジェクトの作成時間を決定する必要がある場合があります.このときABSTRACT FACTORYモードを使用します.ここで依存性はmainからOrder Processingアプリケーションに移行する.すなわち,アプリケーションは具体的な生成方法を知らない.それでも、Order Processingアプリケーションはインスタンスの作成時間を完全に制御します.

依存性注入

作製から分離する強力なメカニズムの1つは注入依存性である.依存性注入は制御逆転技術を依存性管理に応用するメカニズムである.Control Stationでは、1つのオブジェクトが負う補助責任がすべて新しいオブジェクトに転嫁されます.新しい対象は移管の責任のみを負うため、単一責任の原則を守らなければならない.依存性管理コンテキストでは、オブジェクトは依存性自体をインスタンスとする責任を負いません.代わりに、このような責任を他の「専責」メカニズムに任せる.そうすることで制御を逆転させる.初期設定はシステム全体にわたって必要であるため、通常は「main」インスタンスまたは特殊コンテナを「担当」メカニズムとして使用します.
DIコンテナは、要求を受けたときに必要なオブジェクトのインスタンスを作成し、コンストラクタ引数またはコンストラクタメソッドを使用して依存性を設定します.実際に生成されたオブジェクトタイプは、プロファイルで指定するか、特殊作成モジュールでコードで指定できます.
ほとんどのDIコンテナでは、必要に応じてオブジェクトは作成されませんが、ほとんどのコンテナでは、計算の遅延や同様の最適化のために、ファクトリの呼び出しやエージェントの作成方法が提供されています.

関心事を横断する

AOPは,関心事項の横断に対応し,モジュール性を確保するための一般的な方法論である.AOPでは,観点と呼ばれるモジュール構成概念が,「特定の注目点をサポートするには,システム内の特定のポイントの動作方式を一貫して変更しなければならない」と指摘している.簡潔な宣言またはプログラミングメカニズムで実行されることを明示します.
永続性を例にとると、プログラマは永続的に保存するオブジェクトとプロパティを宣言した後、永続性の責任を永続性フレームワークに委任します.これにより,AOPフレームワークはターゲットコードに影響を及ぼさずに動作方式を変更できる.Javaで使われている3つの観点や観点に似たメカニズムを見てみましょう.

Javaエージェント

Javaエージェントは簡単な場合に適しています.たとえば、メソッド呼び出しは、単一のオブジェクトまたはクラスで囲まれます.ただし、JDKにはCGIB、ASM、Javaなどのバイトコード処理ライブラリが必要です.
レクシーのコード量は大きく、きれいなコードを書くのは難しい.

純Java AOPフレームワーク

複数のJavaフレームワーク(Spring AOP、JBoss AOPなど)は、内部でエージェントを使用します.
Springは業務ロジックをPOJOとして実施する.POJOはドメインに純粋に焦点を当てている.POJOは企業の枠組みに依存しない.そのため、テストは概念的に容易で、簡単です.

Bankドメインオブジェクトはデータアクセス者オブジェクト(Data Accessor Object,DAO)としてエージェントされ、データアクセス者オブジェクトはJDBCドライバリソースとしてエージェントされる.
クライアントは、BankオブジェクトからgetAccounts()を呼び出すと信じていますが、実際にはBank POJOの基本操作を拡張したネストされたDECORATORオブジェクトセットの最外周と通信しています.必要に応じて、トランザクション、キャッシュなどにDECORATORを追加することもできます.