JavaScriptを深く理解するシリーズ(21)：S.O.L.I.Dの5原則ISPのインターフェース分離原理を詳しく解説

JavaScriptを深く理解するシリーズ(21)：S.O.L.I.Dの5原則ISPのインターフェース分離原理を詳しく解説_基礎知識

WBOY

リリース： 2016-05-16 16:11:07

オリジナル

1232 人が閲覧しました

はしがき

この章で説明するのは、S.O.L.I.D JavaScript 言語実装の 5 つの原則のうちの 4 つ目、Interface Segregation Principle ISP (The Interface Segregation Principle) です。

英語原文:http://freshbrewedcode.com/derekgreer/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

オブジェクトによって宣言された操作には、操作名、パラメーターオブジェクト、および操作の戻り値が含まれます。これをオペレータの署名と呼びます。

オブジェクト内で宣言されたすべての操作は、オブジェクトのインターフェイスと呼ばれます。オブジェクトのインターフェイスには、このオブジェクトで発生するすべてのリクエスト情報が記述されます。
言語がインターフェイスを表す別の構造を提供するかどうかに関係なく、すべてのオブジェクトには、オブジェクトのすべてのプロパティとメソッドで構成される暗黙的なインターフェイスがあります。次のコードを参照してください:

コードをコピーしますコードは次のとおりです:

/* プライベート変数 */
戻り値 {
binding: function(model) {
/* コード */
}
}
})();

exampleBinder.bind = function(model) {

/* プライベート変数 */
ExampleBinder.modelObserver.onChange(/* コールバック */);
var om = exampleBinder.modelObserver.observe(model);
ExampleBinder.viewAdaptor.bind(om);
返してください;
};

上記の exampleBinder クラスライブラリによって実装された関数は双方向バインディングです。このクラスライブラリによって公開されるパブリックインターフェイスは、bind メソッドです。bind で使用される変更通知とビューインタラクションの機能は、それぞれ、modelObserver と viewAdaptor のパブリックインターフェイスの固有の実装です。その方法。

JavaScript はオブジェクトのコントラクトをサポートするインターフェイスタイプを提供していませんが、オブジェクトの暗黙的なインターフェイスをコントラクトとしてプログラムユーザーに提供できます。

ISP と JavaScript

以下で説明するセクションの一部は、JavaScript のインターフェース分離原則に違反した場合の影響について説明しています。上で見たように、JavaScript プログラムにインターフェイス分離原則を実装するのは残念ですが、静的型付け言語ほど強力ではありません。JavaScript の言語特性により、いわゆるインターフェイスが少し粘着性のないものになることがあります。

秋の実感

静的型付け言語では、ISP 原則に違反する理由の 1 つは実装の失敗です。 Java および C# のインターフェイスで定義されたすべてのメソッドを実装する必要があります。そのうちのいくつかだけが必要な場合は、他のメソッドも実装する必要があります (空の実装または例外のスローによって)。 JavaScript では、オブジェクト内の特定のインターフェイスのみが必要な場合、上記のインターフェイスの実装を強制する必要はありませんが、実装の破損の問題は解決できません。しかし、この実装は依然としてリスコフ置換原則に違反しています。

コードをコピーしますコードは次のとおりです:

var Rectangle = {
領域: function() {
/* コード */
}、
描画: function() {
/* コード */
}
};

var geometryApplication = {
GetLargestRectangle: function(rectangles) {
/* コード */
}
};

var drawingApplication = {
drawRectangles: function(rectangles) {
/* コード */
}
};

長方形の置換が新しいオブジェクト geometryApplication の getLargestRectangle を満たす場合、長方形の area() メソッドのみが必要ですが、LSP に違反します (drawRectangles メソッドで使用できる描画メソッドをまったく使用しないため) ）。

静的結合

静的型付け言語における ISP 違反のもう 1 つの理由は、静的結合です。静的型付け言語では、インターフェイスが疎結合設計プログラムで重要な役割を果たします。動的言語であっても静的言語であっても、オブジェクトが複数のクライアントユーザー間で通信する必要がある場合があります (共有状態など)。静的に型付けされた言語の場合、最良の解決策は、ユーザーとオブジェクトの相互作用を可能にするロールインターフェイスを使用することです。また、オブジェクトは複数の役割を持つ必要がある場合があります)。これは、その実装によってユーザーが無関係なアクションから切り離されるためです。 JavaScript ではそのような問題はありません。動的言語特有の利点によってオブジェクトが分離されているからです。

セマンティックカップリング

動的言語と静的型付け言語の両方で、ISP 違反につながる一般的な理由は、セマンティック結合です。いわゆるセマンティック結合は相互依存です。つまり、あるオブジェクトの動作が別のオブジェクトに依存します。これは、あるユーザーが行動の 1 つを変更すると、別のユーザーに影響を与える可能性があることを意味します。これは単一責任の原則にも違反します。この問題は、継承とオブジェクトの置換によって解決できます。

スケーラビリティ

問題のもう 1 つの理由は、スケーラビリティです。多くの人は、スケーラビリティを示すためにコールバックに関する例を挙げます (ajax で成功した後のコールバック設定など)。このようなインターフェースが実装を必要とし、実装されるオブジェクトに多くの使い慣れたメソッドが存在する場合、ISP は非常に重要になります。つまり、インターフェースが多くのメソッドを実装する必要があるインターフェースになると、その実装は非常に複雑になります。、これらのインターフェイスが非スティッキーな役割を担う可能性があります。これは、私たちがよくファットインターフェイスと呼ぶものです。

概要

JavaScript の動的言語機能により、非スティッキーインターフェイスの実装は静的型付け言語よりも影響力が低くなりますが、インターフェイス分離の原則は依然として JavaScript プログラミングパターンに組み込まれています。