オブジェクト指向 Javascript パート 2 (インターフェイス実装の概要)_js オブジェクト指向

オブジェクト指向の分野においてインターフェイスがいかに重要であるかを示すには十分です。しかし、JS には、他の高レベル オブジェクト指向言語 (C#、Java、C など) のような、あるオブジェクト セットに別のオブジェクト セットと同様の特性が含まれているかどうかを判断するインターフェイス メカニズムが組み込まれていません。幸いなことに、JS には優れた柔軟性があるため (これについては上で説明しました)、インターフェイスの機能を模倣するのが非常に簡単になります。では、インターフェイスとは正確には何でしょうか?

インターフェイスは、類似した動作を持ついくつかのクラス (同じ型または異なる型) 間で統一されたメソッド定義を提供し、これらのクラスが適切に通信できるようにします。

インターフェースを使用する利点は何ですか?簡単に言うと、システム内の同様のモジュールの再利用性が向上し、さまざまなタイプの通信がより堅牢になります。インターフェイスを実装したら、インターフェイス内のすべてのメソッドを実装する必要があります。大規模な Web プロジェクトの場合、同様の機能モジュールを持つ複数の複雑なモジュールは、相互に影響を与えることなく実装を提供するためのインターフェイスを提供するだけで済みます。ただし、インターフェイスが全能ではないことを明確にしておく必要があります。JS は弱い型付け言語であるため、提供するインターフェイスに厳密に従うように他のチーム メンバーに強制することはできませんが、コード仕様と補助クラスを使用してこの問題を軽減することはできます。さらに、システムのパフォーマンスにも一定の影響を及ぼしますが、システム要件の複雑さに応じて決定する必要があります。組み込みのインターフェイスや実装キーワードはないため、JS がどのようにインターフェイスを模倣して実装するかを見てみましょう。

1. インターフェースを実装する最も簡単で効果の低い方法は、アノテーションを使用することです。つまり、コメント内でインターフェイスを使用して、インターフェイスの意図を説明します。

コードをコピー コードは次のとおりです。

/*
interface Composite {
関数 add(子);
関数 getChild(index);
インターフェイス FormItem {
}
*/
var CompositeForm = function(id, name, action) {
// Composite, FormItem
を実装します}
CompositeForm.prototype = {
// Composite インターフェイス
を実装しますadd: function (child) {
//...
},
remove: function(child) {
//...
},
getChild: function( Index) {
//...
}
// FormItem インターフェイスを実装します
save: function() {
//...
}
}


これでは、インターフェイスの機能をうまくシミュレートできず、コンポジット クラスが実際に一連のメソッドを実装していることを確認できず、プログラマに問題を通知するエラーがスローされません。説明以外の効果はありません。すべての一貫性はプログラマーが自発的に行う必要があります。ただし、実装が簡単で、追加のクラスや関数を必要とせず、ドキュメントのサイズや実行速度に影響を与えず、コメントは簡単に削除できるため、再利用性がある程度向上します。他の実装と同じである必要があります。インターフェイス クラスは通信します。

2. プロパティを使用して模擬インターフェイスを確認します。クラスは実装するインターフェイスを明示的に宣言し、属性を通じて対応するインターフェイスが実装されているかどうかを確認します。

コードをコピー コードは次のとおりです。 /*

interface Composite {

関数 add(子);
関数 getChild(index);
インターフェイス FormItem {
}
*/
var CompositeForm = function(id, name, action) {
this.implementsInterfaces = ["Composite", "FormItem"]
//...
}
function checkInterfaces( formInstance) {
if(!implements(formInstance, "Composite", "FormItem")) {
throw new Error("オブジェクトは必要なインターフェイスを実装していません。")
}
/ /...
}
//インスタンス オブジェクトが必要なインターフェイスを実装することを宣言しているかどうかを確認します。
functionimplements(instance) {
for(var i = 1; i < 引数 .length; i ) {
var インターフェイス名 = argument[i];
for(var j = 0; j if(interfaceName ==instance.implementsInterfaces[j]) {
isFound = true;
}
}
if(!isFound) return false;//インターフェースが見つかりませんでした。
}
return true;// すべてのインターフェースが見つかりました。
ここにありますが、インターフェイスを説明するためにコメントが追加されています。ただし、属性implementsInterfacesがCompositeクラスに追加され、クラスがどのインターフェイスを実装する必要があるかを示します。このプロパティをチェックして、対応するインターフェイスが実装されているかどうかを確認します。実装されていない場合は、エラーがスローされます。ただし、対応するインターフェイス メソッドが実際に実装されているかどうかをまだ判断できないという欠点があり、そのインターフェイスが実装されていると「主張」するだけで、対応する作業負荷も増加します。

3. 「アヒルパターン認識」を使用してインターフェースを実装します。クラスがプロパティ検査実装から実装されたインターフェイスをサポートしているかどうかは関係ありません。インターフェイス内のすべてのメソッドがクラス内の対応する場所に存在する限り、インターフェイスが実装されていることを示すだけで十分です。 「アヒルのように歩き、アヒルのように鳴くのであれば、それがアヒルであるかどうかに関係なく、私たちはそれをアヒルだと思います。」補助クラスを使用して、クラスが対応するインターフェイスにすべてのメソッドが存在する (実装されている) かどうかを確認します。存在しない場合は、そのクラスが実装されていないことを意味します。

コードをコピー コードは次のとおりです。

// インターフェイス
var Composite = new Interface( "Composite", ["add", "remove", "getChild"]);
var FormItem = new Interface("FormItem", ["save"]); = function( id, name, action) {
// Composite、FormItem インターフェイスを実装します
}
function checkInterfaces(formInstance) {
Interface.ensureImplements(formInstance, "Composite", "FormItem") ;
//...
}


インターフェイス クラス

コードをコピーコードは次のとおりです。

// インスタンス オブジェクトが必要なインターフェイスのすべてのメソッドを実装しているかどうかを確認するためのインターフェイス クラスです。

var Interface = function(name,messages) {
if( argument.length != 2 ) {
throw new Error("インターフェイス コンストラクターには 2 つの引数が必要ですが、" argument.length " 引数が正確に指定されています。");
this.name = name; 🎜>this.methods = [];
for(var i = 0;i if(typeofmethods[i] != "string") {
throw new Error("インターフェイス コンストラクターは文字列メソッド名を渡す必要があります。");
}
this.methods.push(methods[i]);
}
}
//static class method
Interface .ensureImplements = function(instance) {
if(arguments.length < 2) {
throw new Error("Function Interface.ensureImplements は少なくとも 2 つの引数を必要としますが、正確に渡されます "引数.length " 引数. ");
}
for(var i = 1, len = argument.length; i
var インターフェース = argumentif(interface.constructor != Interface) {
throw new Error("Function Interface.ensureImplements は、少なくとも 2 つの引数が Interface のインスタンスであることを期待します。");
}
for(var j = 0 , mLen = インターフェース.メソッド .length; j
var メソッド = インターフェース.メソッド[j];
if(!インスタンス[メソッド] || インスタンスのタイプ[メソッド] function") {
throw new Error("Function Interface.ensureImplements: オブジェクトは「interface.name」を実装していません。メソッド「メソッド」が見つかりませんでした。");
}
}
}
}


厳密な型チェックは必ずしも必要ではなく、上記のインターフェイス メカニズムは通常の Web フロントエンド開発ではほとんど使用されません。しかし、複雑なシステム、特に類似したモジュールが多数あるシステムに直面する場合、インターフェイス指向のプログラミングが非常に重要になります。 JS の柔軟性が低下しているように見えますが、実際には、同じインターフェイスを実装するオブジェクトを渡すときに正しく解析できるため、クラスの柔軟性が向上し、クラス間の結合が軽減されます。それでは、どのような場合にインターフェイスを使用するのが適切なのでしょうか?大規模なプロジェクトの場合、チームメンバーが多くなり、プロジェクトをより細分化した機能モジュールに分割して確実に進めるために、事前に「プレースホルダープログラム」（インターフェース）を使って説明する必要があります。モジュールの機能や、開発したモジュールに関連する機能を実現するためには、完成したモジュール間で通信を行う際に統一インターフェース（API）を提供する必要があります。プロジェクトが進行するにつれて、要件は変化し続ける可能性があり、それに応じて各モジュールの機能も変化しますが、各モジュール間の通信や上位モジュールに提供される API は常に変更されず、安定性と耐久性が確保されます。建築全体の性別。以下では、特定の例を使用して、インターフェイスの実際のアプリケーションを説明します。クラスが結果オブジェクト (TestResult クラス) を自動的に検出し、インターフェイス実装を使用せずに Web ページ ビューを出力するようにフォーマットするように設計されているとします。

コードをコピー

コードは次のとおりです:

var ResultFormatter = function(resultObject) {
if(!(resultObject instanceof TestResult)) {
throw new Error("ResultFormatter constructor expects a instance of TestResult.");
}
this.resultObject = resultObject;
}
ResultFormatter.prototype.render = function() {
var date = this.resultObject.getDate();
var items = this.resultObject. getResults();
var container = document.createElement("div");
var header = document.createElement("h3");

header.innerHTML = "Test Result from " date .toUTCString();
container.appendChild(header);
var list = document.createElement("ul");
container.appendChild(list);

for(var i = 0, len = items.length; i ) {
var item = document.createElement("li");
item.innerHTML = items[i];
list.appendChild(item);
}
return container;
}

First of all, the constructor of the ResultFormatter class only checks whether it is a TestResult instance, but there is no guarantee that the method getDate() in render will be implemented. and getResults(). In addition, as the needs continue to change, there is now a Weather class that contains getDate() and getResults() methods, but it cannot run the render method because it can only check whether it is an instance of TestResult. Isn't it very speechless? The solution is to remove the instanceof check and replace it with an interface.

Copy code The code is as follows:

//create the ResultSet interface
var ResultSet = new Interface("ResultSet", ["getDate", "getResults"]);
var ResultFormatter = function(resultObject) {
// using Interface.ensureImplements to check the resultObject
Interface.ensureImplements(resultObject , ResultSet);
this.resultObject = resultObject;
}
ResultFormatter.prototype.render = function() {
// keep the same as former
var date = this.resultObject. getDate();
var items = this.resultObject.getResults();
var container = document.createElement("div");
var header = document.createElement("h3");

header.innerHTML = "Test Result from " date.toUTCString();
container.appendChild(header);
var list = document.createElement("ul");
container.appendChild (list);

for(var i = 0, len = items.length; i ) {
var item = document.createElement("li");
item.innerHTML = items[ i];
list.appendChild(item);
}
return container;
}

It can be seen that the render method has not changed in any way. All that changed was adding an interface and using the interface for type checking. At the same time, you can now pass an instance of the Weather class to make the call. Of course, you can also pass an instance of any class that implements the ResultSet interface, making the check more precise and tolerant. With the subsequent introduction of JS design patterns, interfaces will be widely used in factory mode, combination mode, decoration mode and command mode. I hope everyone can savor the benefits that interfaces bring to our JS modular design.