定義
ソフトウェアエンティティ（例えば、クラス、モジュール、関数などは）拡張のためにオープンであるべきであるが、変更のため閉鎖。
定義の解釈
需要が変化していないと判断された場合には、プロジェクトの開発、我々が期待することはできませんが、ほとんどの場合、ニーズが変化しています。それでは、どのようなニーズを変更する状況に対処するには？これは、開いている-について話をする原理を閉じました。
オープン-クローズ原理はクラスを満たすための新しい方法を追加することで、新たな需要があった場合に変更することはもはややってなかった後、クラスのデザインを作ってみるのではなく、既存のクラス変更するために、設計することであると思った（コード）。だから、実際のプロジェクト開発で、それは絶対にそれを修正するために閉じることができるかどうか？答えはノー通常です。もしそうなら、我々は変化点を見つけ、その後、変更のための抽象ポイントを構築し、これらの変更を隔離するために、開発に先立って必要とされています。このように、開閉重要な原則を達成することが抽象的です。
利点
- 柔軟性は、内部コードを変更する必要が機能モジュールの拡張を拡張しないことによって実現することができます。
- 破壊の程度を大幅に低減されるように、安定性は、クラスの基本的な機能の性能は、変更することができません。
概要
デザインパターンの6つの設計原理のために、単一責任単一のクラスに、原則として、メインジョブ記述;リヒター置換原理は、継承階層を破壊しないように強調した。依存関係逆転の原則は、プログラミング・インタフェースを配向させる説明し、インターフェース分離インターフェースの設計原理を合理化するための時間を説明します。デメテルは、カップリングを減らすために教えてくれる、開閉原理は、拡張のためにオープンしようとしているが、修正のため閉鎖しました。
シックス・設計原理ではなく、非常に明確な境界、我々は特定の設計原理に従うときにも、他の設計原則を遵守することがあります。設計原理は、後ろの基礎となるデザインパターンについて話をしたいので、デザインパターン、設計原理については、このシリーズは理解して前に述べました。
ます。https：//www.cnblogs.com/eagle927183/p/3455180.htmlで再現