6つの原則：単一責任、オープン - 閉じ、リヒターは依存、インターフェース分離、デメテルを逆に、交換してください
1.シングル責任原則：
クラスは、機能エリアに対応する業務のためにのみ責任がある、又はように定義することができます。
カテゴリに、一つだけ、彼は変更すべき理由原因。
イデオロギーを導くのシングル責任を達成することである高い凝集を、低カップリング
例：
建設労働者階級は、人々がより強力である、3つのことを行うことができます
public class Builder
{
public void Work()
{
Console.WriteLine("我开始做泥瓦工的活了");
Console.WriteLine("我开始做木工的活了");
Console.WriteLine("我开始做油漆工的活了");
}
}
男（のような）は、非常に多くのものは、あなたが「疲れ」ではありません行うには？彼は、白色点は、あまりにも多くのライブ石工、大工仕事の大工や他のタイプにのみ一時的な1日のラッシュは、あなたがクラスを変更する必要があれば、やって生きるを行う義務、大工コードということである、と述べましたこれは、単一の責任に違反しており、再利用することはできません。
public interface IBuilder
{
void Work();
}
public class TilerBuilder : IBuilder
{
public void Work()
{
Console.WriteLine("我是泥瓦工，开始工作了");
}
}
public class WoodBuilder : IBuilder
{
public void Work()
{
Console.WriteLine("我是木工，开始工作了");
}
}
public class PaintBuilder : IBuilder
{
public void Work()
{
Console.WriteLine("我是泥瓦工，开始工作了");
}
}
2.クローズ原理：
主なアイデア：拡張のためにはオープンですが、修正のため閉鎖しました
ソフトウェアエンティティを延長しなければならないと言われますが、変更することはできません
3.リヒター置換原則：
場所の変更のすべての基本クラスを使用するには、そのサブクラスを交換するために使用することができますが、動作はしていません
https://blog.csdn.net/qq_30631063/article/details/85997672
4.依存関係逆転の原則
高レベルのモジュールは、基礎となるモジュールに依存してはならない、人は両方の抽象に依存している必要があります
要約詳細に頼るべきではありません、詳細は抽象依存すべき
コアアイデア：指向プログラミング・インターフェース
class Book{
public String getContent()
{
return "很久很久以前有一个阿拉伯的故事……";
}
}
class Mother{
public void narrate(Book book)
{
System.out.println("妈妈开始讲故事");
System.out.println(book.getContent());
}
}
public class Client{
public static void main(String[] args){
Mother mother = new Mother();
mother.narrate(new Book());
}
}
运行结果：妈妈开始讲故事
很久很久以前有一个阿拉伯的故事。。
1日の需要が変化しているが、新聞に本を与えていない、場合
class Newspaper{
public String getContent(){
return "林书豪38+7领导尼克斯击败湖人……";
}
}
//这位母亲却办不到，因为她居然不会读报纸上的故事，这太荒唐了，
//只是将书换成报纸，居然必须要修改Mother才能读。假如以后需求换成杂志呢？
//换成网页呢？还要不断地修改Mother，这显然不是好的设计。
//原因就是Mother与Book之间的耦合性太高了，必须降低他们之间的耦合度才行。
私たちは、インタフェースIreaderを紹介します：
我们引入一个抽象的接口Ireader
interface IReader{
public String getContent();
}
Mother类与接口IReader发生依赖关系，而Book和Newspaper都属于读物的范畴，他们各自都去实现IReader接口，这样就符合依赖倒置原则了，代码修改为：
class Newspaper implements IReader {
public String getContent(){
return "林书豪17+9助尼克斯击败老鹰……";
}
}
class Book implements IReader{
public String getContent(){
return "很久很久以前有一个阿拉伯的故事……";
}
}
class Mother{
public void narrate(IReader reader){
System.out.println("妈妈开始讲故事");
System.out.println(reader.getContent());
}
}
public class Client{
public static void main(String[] args){
Mother mother = new Mother();
mother.narrate(new Book());
mother.narrate(new Newspaper());
}
}
5.デメテル：
また、少なくとも知識の原則として知られている
場合は2つのクラスが互いに直接通信する必要はありません、多分クラスは相互作用があるクラスが別のクラスに1つのメソッドを呼び出す必要がある場合は、あなたがすることができ、発生した直接べきではない第三者がコールを転送
デメテルは、クラス間の疎結合の基本的なイデオロギー重視です
6.インターフェイス分離原則：
定義の2種類が一般的にあります。
1.クライアントは、彼の不要なインターフェースに依存しないでください
クラス間2.依存関係は、最小のインターフェイスに基づいている必要があります
我々はインターフェイスを構築する場合3.、我々は単一ではなく、肥大化したインタフェースを確立しようとする必要があり、
分離原則とシングル差の原理をインタフェース：
調査分離インターフェース異なる角度を、単一責任の原則、義務の原理単一責任の単一のクラスおよびインターフェース、インターフェース分離法の原理は、インターフェースできるだけ必要薄く、。
例：
美しさは、我々は一般的に良い顔、良いボディ、良い気性があると思います。その後、我々は美しさ、良い顔、良いボディ、良い気性のインタフェースを定義します。
public interface IPettyGirl
{
void GoodLooking();//要有好的面孔
void NiceFigure();//要有好身材
void GoodTemperament();//要有好气质
}
实现一个具体的美女
public class PettyGirl : IPettyGirl
{
private string name;
public PettyGirl(string name)
{
this.name = name;
}
public void GoodLooking()
{
Console.WriteLine(name + "---有好的面孔");
}
public void NiceFigure()
{
Console.WriteLine(name + "---有好身材");
}
public void GoodTemperament()
{
Console.WriteLine(name + "---有好气质");
}
}
ビューの人々の審美的なポイントの変化は、美しさの定義が変更され、人々はそのような美しい気質などの一般的な、一般的にはボディ、美と定義特に良い気立て女の子を、直面するだろうとしかし、しかし、我々は、インターフェイスの美しさを定義しています三つの条件が熟している美しい気質の美しさの基準の私達の定義ではありません、そして、我々はインターフェイスを定量化する必要があり、私たちの前にあまりにも広義の美しので、二つのインターフェース、1へのインタフェースの美しさは、インターフェイスの美しさの形状です、インターフェースは、美しい気質であるので、私は拡大し、維持しやすい柔軟なインタフェースでした。
//定义俩个接口，外形美女和气质美女
public interface IGoodBodyGirl
{
void GoodLooking();//要有好的面孔
void NiceFigure();//要有好身材
}
public interface IGoodTemperamentGirll
{
void GoodTemperament();////要有好气质
}
//实现接口的类：
public class PettyGirl : IGoodBodyGirl, IGoodTemperamentGirl
{
private string name;
public PettyGirl(string name)
{
this.name = name;
}
public void GoodLooking()
{
Console.WriteLine(name + "---有好的面孔");
}
public void NiceFigure()
{
Console.WriteLine(name + "---有好身材");
}
public void GoodTemperament()
{
Console.WriteLine(name + "---有好气质");
}
}
核となるアイデア：インタフェースができるだけ小さくなるように
あなたがインターフェイスを実装する場合は、インタフェースのすべてのメソッドは、サブクラスで実装する必要があります
拡張：私は、コードに会ったとき、これは困惑外観です。
Q：クラスのメソッド内部インターフェイスはすべてそれを実現しなければならない時にインタフェースを継承？
回答：はい！
例：
//俩个接口
public interface IGoodBodyGirl
{
void GoodLooking();//要有好的面孔
void NiceFigure();//要有好身材
}
public interface IGoodTemperamentGirll
{
void GoodTemperament();////要有好气质
}
public class PettyGirl : IGoodBodyGirl, IGoodTemperamentGirll
{
private string name;
public PettyGirl(string name)
{
this.name = name;
}
public void GoodLooking()
{
Console.WriteLine(name + "---有好的面孔");
}
public void NiceFigure()
{
Console.WriteLine(name + "---有好身材");
}
public void GoodTemperament()
{
Console.WriteLine(name + "---有好气质");
}
}
私の場合
ます。public void NiceFigure（）
{
Console.WriteLineを（名前+ "---良い体を持っています"）;
}
クラスは、それがエラーになり、この方法をコメントしていないと、エラーメッセージ：インターフェイスメンバを実装して何があります
拡張機能2：
