Javaコミュニティでは、異なるプロジェクトのコンポーネントを連携させて cohésive なアプリケーションを構築するのに役立つ軽量コンテナが急増しています。 これらのコンテナの基盤には、ワイヤリングを実行する方法における共通パターンがあり、非常に一般的な名前である「制御の反転」と呼ばれています。 この記事では、このパターンがより具体的な名前である「依存性注入」の下でどのように機能するかを掘り下げ、Service Locator の代替手段と比較します。 どちらを選択するかは、設定と使用を分離するという原則ほど重要ではありません。

コレクションパイプラインは、ある計算を、コレクションを1つの操作の出力として受け取り、それを次の操作にフィードすることによって構成される一連の操作として編成するプログラミングパターンです。（一般的な操作は、フィルタ、マップ、および縮小です。）このパターンは、関数型プログラミング、およびラムダを持つオブジェクト指向言語で一般的です。この記事では、パイプラインを形成する方法のいくつかの例を使用してパターンを説明します。これは、パターンに慣れていない人にパターンを紹介するためと、人々がコアの概念をより簡単に理解して、ある言語から別の言語にアイデアをより簡単に取り入れることができるようにするためです。

従来のフレームワークベースの依存性注入に対する不満に基づいて、部分適用を利用してコンテキストをモジュールに注入する合成戦略を採用しました。テスト駆動開発を設計プロセスとして、またクラスよりも関数に焦点を合わせると、モジュールを明確、クリーン、そしてほとんど意図しない結合から解放することができます。

この記事では、実際のコードベースから一連のリファクタリングについて説明します。これは完璧さを示すことを意図したものではありませんが、現実を表しています。

外部サービスを扱うコードを書くとき、そのアクセスコードを別のオブジェクトに分離することが valuable であることがわかりました。ここでは、凝集したコードをこの分離の共通パターンにリファクタリングする方法を示します。

ループはコレクションを処理する古典的な方法ですが、プログラミング言語で第一級関数が採用されるにつれて、コレクションパイプラインは魅力的な代替手段となっています。この記事では、一連の小さな例を使用して、ループをコレクションパイプラインにリファクタリングする方法を検討します。

依存性逆転の原則（DIP）は90年代初頭から存在していましたが、問題解決の途中で忘れがちです。いくつかの定義の後、私が実際にプロジェクトで使用したDIPのアプリケーションをいくつか紹介しますので、あなた自身の結論を形成するための例がいくつかあります。

集約は、ドメイン駆動設計のパターンです。 DDD集約は、単一のユニットとして扱うことができるドメインオブジェクトのクラスターです。例として、注文とその明細項目があります。これらは別々のオブジェクトになりますが、注文（明細項目とともに）を単一の集約として扱うと便利です。

JSONデータ構造をサーバーに流すことは、最近よく見かけるようになっています。 JSONドキュメントは、集約指向データベースまたはリレーショナルデータベースのシリアル化されたLOBを使用して、直接永続化できます。 JSONドキュメントは、Webブラウザに直接提供したり、サーバー側のページレンダラーにデータ転送するために使用したりすることもできます。 JSONがこの方法で使用されている場合、オブジェクト指向言語を使用すると、JSONをオブジェクトに変換して再度レンダリングする必要があるため、プログラミングの労力が無駄になると言っている人がいます。私は無駄な点については同意しますが、それはオブジェクトの問題ではなく、カプセル化の理解不足であると主張します。

プログラミングでは、オブジェクトの基本的な概念は、データと動作のバンドリングです。これは、一連の関連関数を作成するときに共通のデータコンテキストを提供します。また、オブジェクトがそのデータへのアクセスを制御できるようにするデータ操作へのインターフェースを提供し、派生データをサポートし、データの無効な変更を防ぐことを容易にします。多くの言語は、オブジェクトの定義として機能するクラスを定義するための明示的な構文を提供します。ただし、第一級関数とクロージャを持つ言語がある場合は、これらの構成要素を使用して、オブジェクトとしての関数パターン（Eugene Wallingfordによって最初に記述された）を使用してオブジェクトを作成できます。

私の見解では、GoFはオブジェクト指向設計について書かれた最高の、おそらくあらゆるスタイルの設計の中で最高の著書です。この本はソフトウェア業界に大きな影響を与えました。GoFパターンで埋め尽くされているJavaと.NETライブラリを見てください。

ゲッターメソッドを見ると、口の左側に痙攣が起き、彼らの戦闘斧が素早く引き抜かれ、別のゲッターが容赦なくクラスから切り落とされると満足のいく叫び声が上がり、すぐに男らしいゲッター撲滅者の足元で感謝のエクスタシーに陥ります。

制御の反転の同義語。

すべてのクラスを取得し、それをインターフェースとペアリングするというプラクティス。そのため、ICustomerとCustomer、またはCustomerとCustomerImplなど、ペアになっているものが表示されます。多くの点で、これは各クラスのヘッダーファイルのC / C ++の習慣を反映していますが、この場合、インターフェースと実装は実際には別々のタイプです。

制御の反転は、フレームワークを拡張するときに遭遇する一般的な現象です。実際、それはしばしばフレームワークの決定的な特徴と見なされます。

遅延初期化は、変数（OOコンテキストでは通常はクラスのフィールド）を最初にアクセスしたときに初期化する手法です。正規の形式は次のようになります

必須インターフェースとは、そのインタラクションで使用できるように、サプライヤーコンポーネントが何をする必要があるかを指定する、インタラクションのクライアントによって定義されるインターフェースです。

尋ねるな、指示せよとは、オブジェクト指向とは、データをそのデータで動作する関数とバンドルすることであることを人々に思い出させるのに役立つ原則です。オブジェクトにデータを求めてそのデータに基づいて行動するのではなく、オブジェクトに何をするかを指示する必要があることを思い出させてくれます。これは、データに合わせて動作をオブジェクトに移動することを推奨しています。

モジュールによって提供されるすべてのサービスは、ストレージまたは計算によって実装されているかどうかを裏切らない、均一な表記法を通じて利用できる必要があります。

-- バートランド・メイヤー

バートランド・メイヤーは、彼の非常に影響力のある著書「オブジェクト指向ソフトウェア構成」でこの原則を作り出しました。

この原則の本質的なポイントは、人物オブジェクトがあり、その年齢を尋ねた場合、年齢がオブジェクトの格納フィールドであるか計算値であるかに関係なく、同じ表記を使用する必要があるということです。それは事実上、その人物のクライアントは、年齢が格納されているか計算されているかを知るべきではなく、気にするべきでもないことを意味します。