发几个类设计原则，看得懂就说明你们有点基础了

1.SRP单一职责原则[适用于类功能]
(就一个类而言,应该仅有一个引起它变化的原因.)
详细说明:
如果一个类承担的职责过多,就等于把这些职责耦合在一起.
一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力.
这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏.
结论:
它是所有类设计原则最简单的,也是最难正确使用的.
我们会自然的把职责结合在一起,软件设计真正要做的内容就是发现职责并把那些职责相互分离.



2.OCP开放-封闭原则[适用于类抽象]
(软件实体(类,模块,函数...)应该是可以扩展的,但是不可以修改.)
详细说明:
OCP=对于扩展是开放的,对于修改是封闭的.
如果程序中的一处改动就会产生连锁反应,导致一系列相关模块的改动,那么设计就有臭味.
OCP建议我们如果要对系统进行重构,就只需要添加新的代码,而不必改动已经正常运行的代码.
结论:
在许多方面,OCP都是面向对象设计的核心.
尊循它可以带来巨大的好处(程序的灵活性,可重用性,可维护性).
在代码中肆意使用OCP也不是一个好主意.
正确的做法是：开发人员仅仅对程序中呈现频繁变化的部分做出抽象！拒绝不成熟的抽象和抽象本身一样重要!

3.LSP Liskov替换原则[适用于类层次]
(子类型必须能够替换掉它们的基类型.)
详细说明:
Barbara Liskov在1988年说道:
Liskov替换性质:若对每个类型S的对象O1,都存在一个类型T的对象O2,
在所有针对类型T编写的程序P中,用O1代换O2后,程序P行为功能不变,则类型S是类型T的子对象.
结论:
LSP是使用OCP开放-封闭原则成为可能的主要原则之一,
正是子类型的可替换性才能用基类类型(基类引用或者指针)的模块在无需修改的情况下就可以扩展.
这种可替换性是开发人员可以隐式依赖的东西.
因此,如果没有显示的强制基类类型的契约,那么代码就必须良好并明显的表达出这一点.
术语"IS-A"不能作为子类型的定义,
子类型的正确定义是"可替换性","可替换性"可以通过显式或者隐式的(动态绑定必须用基类类型)契约.

4.DIP依赖倒置原则[适用于类层次]
(抽象不应该依赖细节.细节应该依赖抽象.)
详细说明:
a.高层模块不应该依赖于低层模块,二者都应该依赖抽象(使用接口或者虚类来连接).
b.抽象不应该依赖于细节,细节应该依赖于抽象.
结论:
使用传统的过程化程序设计方法所创建出来的依赖关系结构和策略是依赖于细节.
DIP使得细节和策略都依赖于抽象,并且常常为客户定制服务接口.
事实上,这种依赖关系的倒置是好的面向对象的程序设计的标记.
DIP正确应用对于可重用框架是必须的,对于构建在变化面前富有弹性的代码也是非常重要的.
由于抽象和细节被DIP彼此隔离,所以代码也非常容易维护.

5.ISP接口隔离原则[适用于类的接口]
不应该强迫客户程序依赖于它们不用的方法.
接口属于客户,不属于它所在的类层次结构.
详细说明:
分离客户就是分离接口.分离接口有2种方法:委托和多重继承
接口隔离原则是用来处理胖接口所具有的缺点.
如果类接口不是内聚的,就表示该类的接口是胖的,需要减肥.
减肥的原则是接口分成多组方法,每一组方法都服务于一组不同的客户程序!
客户程序面对的就是多个具有内聚接口的抽象基类.

结论:
胖类会导致它们的客户程序之间产生不正常的有害的耦合关系.
当客户程序要求胖类进行一个改动时,会影响到所有其它户程序.
因此,程序应该仅仅依赖于它们实际调用的方法.
通过把胖类的接口分解为多个特定的客户程序的接口,可以实现这个目标.
每个特定于客户程序的接口仅仅声明它自己调用的函数.
解除了类的客户程序之间依赖关系,使它们互不依赖.