カプセル化は単なるブラックボックスではなく芸術です。 問題があります-修正、再定義、変更などができないコード それが使用されている同じプロジェクトで。 すべてを構成、再定義、および変更する必要があります。 正しい状況で呼ばれ、世界を救う普遍的な兵士であり、新しい兵士の誕生の期待ではない。 そして解決策は、ライブラリのソースコードを修正しないことです。 これは、ソースコードが単純に不足しているため、時間がかかるプロセスです。 これらの言葉は簡単に言うことができますが、プログラミング言語での意味とそれらに対応する方法を理解するのは困難です。
カプセル化の問題があると言いたいのですが、解決中です。 ブラックボックスは、目標を達成するために使用される完成品、および目標を達成するためにフォームが作成される素材として見ることができます。 描画にペイントを使用し、新しいペイントを作成するアーティストの例を挙げることができます。 将来の使用のためにペイントを構成します。 しかし、塗料の代わりにプラスチシンを使用してアーティストに贈ると、プラスチシンを混合しても望ましい色のプラスチシンを得ることができません（面倒なプロセス）。 この場合、粘土は塗料よりも劣ります。
したがって、ブラックボックスの使用は2つのカテゴリに分類できます。
- 最終製品（製品、MS、Oracleなどの販売とサポートから利益を得る企業に関連。このため、再構成できないクラスを提供します）
- 仲介者（オープンソース企業に関連しますが、逆説的に、彼らは可能な限りクラスを構成する機会を与えないことを与えることを忘れるか、または疑いません）
外部ライブラリの場合、「完成品」を正当化することはできますが、制限が大きすぎるとプログラマーは悪魔的な道を歩むことになります。 仲介者の目的である、便利な隠しボックスは、もちろん、実装の複雑さからの抽象化を支援するだけでなく、可能な限り構成して、その使用を拡大できるようにすることです。
再利用コード用のライブラリ、ブラックボックスを作成する際に考慮すべき原則：
- オーバーライドされました。 メソッドをオーバーライドできるように、accessステートメントでメソッドを作成します。 （少なくとも保護されている、アクセスレベルが保護されているよりも低いことはほとんどありません）
- 関数をオーバーロードします。 同じ機能の多様なシグネチャにより、メソッドのパラメーターの数を削減
- 静的は悪です。 静的変数、悪の関数、通常の変数と関数に置き換える必要がある
- コントロールインスタンス。 この作成をオーバーライドする機能がない限り、新しいオブジェクトを作成しないでください。 コード内で明示的にnew演算子を使用しないでください。これらのオブジェクトに対してsettersメソッドを使用し、ファクトリーがオブジェクトを作成するか、オーバーライドされるオブジェクト関数を作成してください。
- 最後のバージョンは悪です。 関数およびクラスにfinalキーワードを使用しないでください。 関数とクラスのオーバーライドを許可する
- アトミック すべての論理ユニットを小さなメソッドに分離します
PS：トピックが興味深い場合は、OOSILAの原則の使用例を準備します。
更新：非表示ボックス=>ブラックボックス