私はあなたがこれでどこに行くのか本当にわかりません...
しかし、原因をさらに進めるために:
var Class = (function () {
var private_data = 1234,
private_method = function (x) { private_data += x; },
public_method = function (x) { private_method(x); },
other_method = function () { return private_data; },
public_interface = {
add : public_method,
toString : other_method
};
return public_interface;
}());
これで、インターフェイスにプログラムしました。
この特定のインターフェースはとに.add
なり.toString
ます。
プライベート値は同封されているため、改ざんされても安全です。変更されていない限り、
add
アクセスする機能があります。private_method
add
事後に、このようなことをしようとすると、次のようになります。
Class.add = function (x) { steal(private_data + x); };
それはうまくいきません。
新しい関数には、プライベートデータへの参照がありません。
したがって、外部の人やプログラムがパブリックインターフェイスを改ざんする可能性はありますが、内部の状態は問題ありません。
プログラムが改ざんされた場合、または他の保護されていないクラスが危険にさらされた場合でも、プログラムは壊れてしまう可能性がありますが、これは問題なく動作し、プログラムが行う必要のある内部呼び出し(画面を更新した場合、タイマーで)、それでも完全に起こります。
カプセル化のもう1つのポイントは、人々に提示したいインターフェースを選択することです。
クラス内に30個のヘルパー関数を含めることもできますが、外部アプリケーションにそれらのいくつかへのアクセスを許可したい場合があります。
そして、それらのパブリックメソッドはプライベートデータ/メソッドにアクセスでき、クライアントに実行させたいことは何でも実行できます。それ以上のことは何もできません。
これがアプリケーションプログラミングインターフェイスです。
BlogManager
私がクラスを持ちたいと思ったら、それは巨大かもしれません。
データベースからデータを取得したり、並べ替えたり、テンプレートを設定したり、ビューと通信したりできるようにしたいのかもしれません...フィルタリングできるようにしたいのですが、あらゆる種類の処理を実行できるようにしたいのです。 ..
しかし、私はエンドユーザーにそのすべてを行わせたくありません。
エンドユーザーにしてほしいのは.request(options);
or.create(blog_post);
または.update(blog_post);
or.delete(blog_post);
です。
エンドユーザーにこれらの4つのメソッドを与えると、BlogManager内で行われている他の何十ものことに触れて、すべてを期待どおりに機能させることはできません。
それはインターフェースへのプログラミングです。
将来、結果をフィルタリングするためのより良い方法を見つけたとき、データベースを変更したとき、またはデータストレージの構造を変更したとき、内部で何をするかは重要ではありません。クラス、外側はまだ同じように見え、同じように動作するためです。
同じパブリックメソッド、同じ入力タイプ、同じリターンタイプがある場合... ...その後、内部でやりたいことが何でもできます。
ただし、インスタンス化されたオブジェクトの代わりに、実際のコンストラクター関数 を返すための即時のケースは多くありません。
関数の戻り値の代わりに、関数を返すケースが多くないのと同じように。
非同期プログラミングは別として。