终于到了可以啃设计模式这一环节了。这里针对自己的理解来对SOLID五种模式进行分析。按照1，2，3，4，5的顺序对应SOLID，但1，4和2，3，5所处的部分不同，但是这些原则其实使用的时候是组合起来的。
组件原则部分
1.单一职责原则（The Single Responsibility Principle）
定义：不要存在多余一个导致类变更的原因，即，一个类只负责一项职责。
问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。
从使用角度来看：当需要修改某个类的时候原因有且只有一个。换句话说就是让一个类只做一种类型的责任，当这个类需要承担其他类型的责任的时候，就需要分解这个类。
这个原则我认为应该是理解上最容易的一个。假设有个流程代码实现如下三个功能。
{
用户输入消息代码---->用户输入消息类方法
处理消息代码---->处理消息类方法
打印消息代码---->打印消息类方法
}
其实，从上面的框架就可以看出来，这段代码实现三个功能，单一职责原则就是，我们让每项功能都独立实现，使用时调用相应的类方法即可，而不需要每次对代码进行上下文修改。
该方法的优点：
1.可以降低类的复杂度，一个类负责一项职责，其逻辑会比负责多项职责简单。
2.提高类的可读性，提高系统的可维护性。
3.变更引起的风险降低，变更是必然的，如果SPR原则遵守的很好，当修改一个功能的时候，可以显著降低对其他功能的影响。
无论面向对象编程还是面向过程编程，只要是模块化的程序设计，都需要遵守这一原则。
缺点：
当项目很大的时候， 可能会有很多功能，会有爆炸式的类，这种时候就需要考虑如何用文件夹设计你的工程项目，使其易读。
4.接口分离原则(The Interface Segregation Principle)
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
从使用角度来看： 不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总结口要好。
interface IAA:basicinterface, additional1interface
{
base functions
additional1 functions
}
interface IBB:basicinterface, additional2interface
{
base functions
additional2 functions
}
class AA: IAA
{
***
}
class BB:IBB
{
***
}
从上面的接口可以看出来，我们有两个接口AA，BB，这两个接口分别都继承同一个公共接口和不同的功能接口，我们可以以员工为实体例子来思考，不同的员工都有基本信息，但是根据职位的不同，员工的可以获得的职权功能也是不同的，不同部门的权限也是不同的。我们不应该把所有功能都放在一个接口里让类去实现，而是要把接口单一化，可以继承多个接口，但不要继承一个庞大但有很多无用功能的接口。
注意：使用ISP规则的时候：
1.接口设计一定要谨慎，不能过小或者过大，过小的接口会让文件十分琐碎，但是过大的接口则会使修改时的依赖增大
2：为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。
3.对外交互尽量少，用最小的几口完成最多的事，要加强内聚。
联系原则部分
2.开闭原则（The Interface Segregation Principle）
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
从使用角度：软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程中最抽象、最难理解的一个。
ISP原则，其实就是要我们不要直接继承类，而是继承接口来实现，我们不改变接口，只改变实现方式或增加接口。
class model--->提取成接口
{
string name,
string address,
这里要新添加一个方法。-->为这新的方法在接口中书写默认值，然后赋值到符合这个属性的不同的类。
}
我们在基础类里面对这个方法需要的属性也是需要增加的。但是在实现的时候，我们可以根据功能性来进行分离，还是以公司员工举例，原来只有基本信息功能，我们现在要添加经理，还是CEO的功能，我们需要在基础员工信息里面添加这两个属性（默认为false），然后在创建员工档案的时候，分为普通员工，经理，CEO这些不同的员工来进行创建。但这三者在基础的接口是一样的，但是在继承接口实现不同类来创建不同的账号权限。
3.里氏替换原则(The Liskov Substitution Principle)
定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
定义2：所有引用基类的地方必须能透明地使用其子类的对象。
问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
从使用角度：当子类的实例应该能够替换任何超类的实例时，它们之间才具有is-a关系
个人感觉，这个模式出故障可能的一个问题在于定义接口的时候，分工不是那么明确，可能把可以分离的功能放在一起，当定义实类或子类的时候，有些定义是需要那些功能，有些是不需要的，如果主程序原来是需要的，用不需要功能的子类替换的时候就会出现问题。这个时候，解决方法应该还是要把接口分开。当然可能还有其他情况，这里的规则就是子类可以替换父类而使程序没有错误。
5.依赖倒置原则（Dependency Inversion Principle）
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
static void Main(string[] args){
Person owner = new Person{
FirstName = "Tia",
LastName = "Bob",
PhoneNumber="13242"
}
Chore chore = new Chore{
ChoreName = "Take the task",
Owner = owner
}
chore.Performance(2);//进行工作时间累计
chore.CompleteChore();//提示工作完成
}
因为高层不应该直接依赖低层代码，我们应该看到的代码是功能会被执行，而不是怎么执行。所以，我们把高层代码里可以看到的new **都放到一起，且用相应继承的接口类型来定义返回值。这里只是展示了main代码里的new，其他高层代码也需要这么处理。
public static class Factory
{
public static IPerson Create Person（）
{
return new Person();
}
public static IChore CreateChore()
{
return new Chore();
}
}
则之前那篇代码可以改成
{
IPerson owner = Factory.CreatePerson();
owner.FirstName="";
owner.LastName="";
owner.PhoneNumer="";
IChore chore = new Factory.CreateChore();
chore.ChoreName="";
chore.Owner = owner;
....
}
总结：
设计模式的出发点是为了让我们的代码变得更鲁棒，更能适应变更而不会因为变更带来很大的工作量。
规划好模块的属性和方法，合理的设计接口，类实现通过继承相应的接口来实现。接口定义需要的基本功能，我们对接口进行拼装可以生成更复杂的专门接口。最后类是通过接口来进行实现的。
设计是为了更好的合作和维护。但最重要的不是代码，是人，是团队，坏代码可以通过学习实践，几天改写成好代码，但是坏团队不会几天变成好团队。
