通常これらはscriptタグ経由でインストールされ、なんらかのグローバル変数を宣言します。アプリケーションはグローバル変数を参照して何らかのAPIを呼び出します。)を介して直接的に結合していることです。参照してしまうと大きく2つの悪影響があります。ひとつはプラットフォーム非依存性を損ねること。ひとつはメンテナンス性を損ねることです。オブジェクトはWebブラウザで実行されるJavaScriptにしか存在しません。依存したソースコードはWebブラウザ上でしか実行できなくなります。Worker上でアプリケーションを部分的に実行することがあるかもしれません。ようなプラットフォーム固有のAPIに依存した実装は最小限にすべきです。ひとつのメンテナンス性の問題は、アプリケーション内外の境界があいまいとなり、ソースコード間の依存関係が複雑になることが原因です。サードパーティSDKが宣言するグローバル変数の名前が変わったら、そのグローバル変数に依存しているソースコードをすべて修正することになるでしょう。根本的にサードパーティSDKはアプリケーションとは隔離された存在です。アプリケーションコンフィグの章でも述べた通り、アプリケーションの内と外の境界を明確にし、接点を最小限にしておくことが重要です。することでアプリケーション内の秩序を維持し、外部要因に振り回されずにメンテナンスできます。アプリケーションコンフィグの管理/season-4-dependency-injection/app-configサードパーティSDKを抽象化するサードパーティSDKをラップ(wrap)するサービスを作成することで、アプリケーションから直接サードパーティSDKを参照しないように抽象化できます。ここからは架空のサードパーティSDKを題材にして具体的な実装方法を学んでいきましょう。次のような簡単なスクリプトをHTMLファイルに記述します。};</script>アダプタークラスの作成まず最初に、サードパーティSDKをラップするためのアダプター(Adapter)クラスを作成します。このアダプターだけがSDKの具体的なAPIを知っていて、アプリケーションはアダプターを経由してAPIを呼び出します。アダプターにサードパーティSDKに関する責務を委譲します。依存していないということです。型のオブジェクトを受け取る予定になっています。Promiseでラップしています。アプリケーション外のAPIをアプリケーション内から完全に隠蔽するのがアダプターの責務です。ようなグローバル変数に依存していないため、テストコードもシンプルになります。使って簡単にテストできます。クラスを提供するためのプロバイダーを定義しましょう。変数を取り出してインスタンス生成に使用します。関数を使いますが、非同期読み込みの場合はそれに応じて適切なPromiseを渡しましょう。モックオブジェクトを利用すれば、このプロバイダーが期待通りに振る舞うかどうかを簡単にテストできます。プロバイダーを定義しましたが、このプロバイダーはどこに追加すべきでしょうか。エントリポイントは各プラットフォームごとに用意されます。このファイルはAngularアプリケーションの中でプラットフォームに依存する責務を集約できる場所だということです。関数は、オプショナル引数としてプロバイダー配列を受け取ります。結合され、ブートストラッピングに利用されます。プラットフォームに依存するサービスはプラットフォームプロバイダーを利用することで、アプリケーション内部をプラットフォーム非依存の状態に保つことができます。関数に引数を渡しましょう。provideEventTrackerAdapterInBrowser(window)]).bootstrapModule(AppModule);回りくどい実装に見えるかもしれませんが、グローバル変数に依存するコードを最小限に抑えることで、ユニットテストが可能な範囲を広げています。サーバー用のプロバイダーを追加するだけで、アプリケーション側には一切変更を加える必要がありません。次の図のように、プラットフォームごとの差異をアプリケーション内外の境界で吸収するような設計が、アプリケーション内のメンテナンス性を高めるポイントです。GitHubContentsサードパーティSDKとの連携windowへの参照を避けるべき理由サードパーティSDKを抽象化するアダプタークラスの作成プロバイダーの定義プラットフォームプロバイダ。