序文
この章では、Solid JavaScriptの5つの主要な原則、インターフェイス分離原理の実装の第4章を説明します。
元の英語のテキスト：http：//freshbrewedcode.com/derekgreeer/2012/01/08/solid-javascript-the-interface-segregation-principle/
注：この記事の著者は非常に感動的であるため、叔父もそれを理解するために落ち込んでいます。あなたが好きなようにそれを読んでください、それにとどまらないでください。
インターフェイス分離の原理の説明は次のとおりです。
コードコピーは次のとおりです。
クライアントは、使用しない方法に依存することを強制されるべきではありません。
顧客は、使用していない方法に頼らざるを得ないでください。
ユーザーが依存するインターフェイス方法は、他のユーザーによってのみ使用され、使用しない場合、これらのインターフェイスを実装する必要があります。言い換えれば、ユーザーが他のユーザーが使用するが使用されているインターフェイスに依存している場合、他のユーザーがインターフェイスを変更すると、インターフェイスに依存するすべてのユーザーが影響を受けます。これは明らかに開閉の原則に違反しており、私たちが期待するものではありません。
インターフェイス分離原理ISPは、単一の責任に多少似ています。どちらも機能的責任を集約するために使用されます。実際、ISPは、単一の責任を持つプログラムをパブリックインターフェイスを持つオブジェクトに変換することを理解できます。
JavaScriptインターフェイス
JavaScriptの下でこの原則をどのように順守しますか？結局のところ、JavaScriptにはインターフェイスの機能がありません。インターフェイスが特定の言語で提供される抽象型を介して契約を確立し、デコープルしたい場合、それは大丈夫だと言えますが、JavaScriptには別の形式のインターフェイスがあります。本のデザインパターンの再利用可能なオブジェクト指向ソフトウェアの要素では、インターフェイスの定義が見つかりました。
http://www.amazon.com/design-patterns-elements-reusable-object-oriented/dp/0201633612
オブジェクトによって宣言された操作には、操作名、パラメーターオブジェクト、および操作の返信値が含まれています。オペレーターの署名と呼びます。
オブジェクトで宣言されたすべての操作は、このオブジェクトのインターフェイスと呼ばれます。オブジェクトのインターフェイスは、このオブジェクトで発生するすべての要求情報を示しています。
言語がインターフェイスを表すための個別の構造を提供するかどうかに関係なく、すべてのオブジェクトには、オブジェクトのすべてのプロパティとメソッドで構成される暗黙のインターフェイスがあります。次のコードを参照してください。
コードコピーは次のとおりです。
var emblesbinder = {};
emblesbinder.modelobserver =（function（）{
/* private変数*/
戻る {
観察：function（model）{
/* code*/
NewModelを返します。
}、
onchange：function（callback）{
/* code*/
}
}
}）（）;
emblesbinder.viewadaptor =（function（）{
/* private変数*/
戻る {
bind：function（model）{
/* code*/
}
}
}）（）;
emblesbinder.bind = function（model）{
/* private変数*/
ExampleBinder.ModeloBServer.OnChange（/ *コールバックコールバック */）;
var om = emblybinder.modelobserver.observe（model）;
emblesbinder.viewadaptor.bind（om）;
OMを返します。
};
上記のExampleBinderクラスライブラリは、双方向の結合を実装しています。このクラスライブラリによって公開されたパブリックインターフェイスはBINDメソッドであり、バインドで使用される変更通知とビューインタラクションの機能は、それぞれ別々のオブジェクトModelObserverとViewAdaptorによって実装されます。これらのオブジェクトは、ある意味では、パブリックインターフェイスバインドメソッドの特定の実装です。
JavaScriptはオブジェクト契約をサポートするインターフェイスタイプを提供していませんが、オブジェクトの暗黙的なインターフェイスは、契約としてプログラムユーザーに提供されることができます。
ISPおよびJavaScript
以下で説明するサブセクションのいくつかは、JavaScriptのインターフェイス分離原理に違反することの影響です。上記のように、JavaScriptプログラムでインターフェイス分離の原則を実装するのは残念ですが、静的に型間の言語ほど強力ではありません。 JavaScriptの言語特性により、いわゆるインターフェイスを少し焦げ付き防止にすることがあります。
pr落の実現
静的にタイプされた言語では、ISPの原則に違反する理由の1つは、退化した実装です。 JavaおよびC＃のすべてのインターフェイスで定義されているメソッドを実装する必要があります。それらのほんの一部しか必要ない場合は、他の方法も実装する必要があります（空の例外またはスローの例外によって実装できます）。 JavaScriptでは、オブジェクト内のいくつかのインターフェイスのみが必要な場合、上記のインターフェイスの実装を強制する必要はありませんが、退化する実装の問題を解決することはできません。ただし、この実装は依然としてリヒターの交換の原則に違反しています。
コードコピーは次のとおりです。
var rectangle = {
エリア：function（）{
/* code*/
}、
描画：function（）{
/* code*/
}
};
var geometryapplication = {
getLargestRectangle：function（rectangles）{
/* code*/
}
};
var DrawingApplication = {
DrawRectangles：function（rectangles）{
/* code*/
}
};
新しいオブジェクトGeometryApplicationのgetLargestRectangleを満たすための長方形の代替品が、長方形領域（）メソッドのみが必要ですが、LSPに違反します（DrawRectanglesメソッドでのみ使用できる抽選方法を使用できないため）。
静的結合
静的にタイプされた言語でISP違反のもう1つの理由は、静的な結合です。静的にタイプされた言語では、インターフェイスは、ゆるく結合された設計プログラムで大きな役割を果たします。動的言語であろうと静的言語であろうと、オブジェクトが複数のクライアントユーザー（共有状態など）間で通信する必要がある場合があります。静的にタイプされた言語の場合、最良の解決策はロールインターフェイスを使用することです。これにより、ユーザーは、ユーザーを分離して無関係な動作を分離するための実装としてオブジェクト（複数のロールである必要がある場合があります）と対話できます。オブジェクトは動的言語の独自の利点によって切り離されるため、JavaScriptにはそのような問題はありません。
セマンティックカップリング
ISPに違反する一般的な理由の1つは、動的な言語と静的な型言語の両方であり、これはセマンティックカップリングです。いわゆるセマンティックカップリングは相互依存性です。つまり、オブジェクトの動作は別のオブジェクトに依存します。つまり、ユーザーが動作の1つを変更すると、別のユーザーに影響を与える可能性があります。これはまた、単一の責任の原則に違反します。この問題は、継承とオブジェクトの置換によって解決できます。
スケーラビリティ
問題のもう1つの理由は、スケーラビリティに関するものです。多くの人々は、コールバックについて例を挙げて、スケーラビリティ（AJAXでの成功後のコールバック設定など）を実証します。このようなインターフェイスに実装が必要で、この実装のオブジェクトに多くの馴染みのある方法またはメソッドがある場合、ISPは非常に重要になります。つまり、インターフェイスインターフェイスが多くのメソッドを実装する必要がある場合、その実装は非常に複雑になり、これらのインターフェイスが染みやすい責任を引き受ける可能性があります。これは私たちがよく言及する脂肪界面です。
要約します
JavaScriptの動的な言語特性により、非スティックインターフェイスの実装は静的に型付けされた言語よりも影響力が低くなりますが、インターフェイス分離の原理はJavaScriptプログラミングモデルに依然として機能を持っています。