如今编程的主流语言基本上都是面向对象的。如C#，C++，JAVA。咱们在使用时，已经构造了一个个的类。可是每每因为咱们在类内部或外部的设计上存在种种问题，致使尽管是面向对象的语言，倒是面向过程的逻辑，甚至维护起来异常困难。每次增长或修改功能都要改动不少的代码，如履薄冰。而面向对象的六大原则主要的目的，就是咱们如何设计类，更能很好的利用面向对象的特性。程序员
1）单一职责原则
一个类永远只有一个职责。编程
一套软件就像是一个团队，每一个类就是团队中的一个成员。团队若是想稳定的发展。这些类就要各司其职，分工明确。若是类之间的功能出现了混淆，那么软件的总体结构就会很是的混乱。就像管理学中的一句话，若是一个职责由每一个员工负责，那么这个职责就没有员工在负责。 这个原则的概念很是简单，也是很是基础的。不少人尽管没有学习过面向对象的思想，可是常常写代码以后也会不自觉的遵照这个原则。设计模式
Ps：在遵循单一职责原则的时候，经常会遇到职责扩散的问题。什么是职责扩散呢？这里简单说下，在平常生活中，咱们在对职责分类时，发现不少日常不受重视的职责，可是这些职责又不能忽视。因而就依次累加，最后分起类来会无穷无尽（有兴趣的读者能够参考下长尾定理）。为了解决这种问题，咱们就须要有一些类，他的职责比较综合（相似于“其它”）。相似于一个帮助类。可是这个类又不能太复杂了，不然咱们就应该考虑怎么把这个类分离开来。究竟这个类的复杂程度到了何时状况下，咱们就应该拆分呢？这个须要程序员根据软件自身的复杂状况来判断，没有一个统一的标准。post
2） 里氏替换原则
“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”学习
“继承必须确保超类所拥有的性质在子类中仍然成立“设计
这个原则主要是为了体现面向对象的“继承”特征来提出的。 它的主旨就是，可以使用基类的地方，必然也可以透明的使用其子类，而且保证不会出错。为了保证这种透明的无差异的使用，子类在使用时不该该随意的重写父类已经定义好的非抽象的方法。由于这些非抽象方法，相似于某种职能或契约，当父类保持这种约定时，子类也应该遵循并保证该特性，而非修改该特性。 咱们在写代码的时候，若是一个参数设定的是基类（或接口、抽象类），那么咱们传送子类进去，同样能够正常使用。由于基类相对于父类，只是一个更丰富，更具体，更详细的表现形式。而不该该出现，传入父类运行某种方法没有问题，但是传入子类运行时就报错了。这在平常生活中也能够理解，汽车做为父类，他下面有卡车、轿车。轿车下边又有两厢，三厢等不一样的继承。可是不管是哪一种汽车（父类）的职能，对于他的子类（卡车或轿车）都应该具备相同的职能，而不是相反的职能。以致于子类的子类（本例中是两厢轿车）也应该拥有汽车一致的功能。对象
咱们在写代码中，很容易出现复写了父类的方法后，父类的方法发生了改动，而未考虑到子类的方法也须要做出相应的改动，致使代码出现错误。 通俗一点，能够理解为子类是遗传自父类的。他在各类职能上也应该一脉相承自父类。而不该该随意改变。 blog
Ps 为何要叫里氏替换原则呢？这是由于最先提出这个理论的人姓里Liskov。这是计算机中少有的以姓氏命名的东西。继承
3）最少知道原则
Only talk to your immediate friends。（已经第二次引用英文，是否是很厉害23333）接口
永远只和你的朋友交流。
咱们在学习编程的初期，都会有人告诉咱们要遵循“高内聚，低耦合”。而OO中也将“封装”做为对象的基本特征之一。最少知道原则其实体现的就是“高内聚，低耦合”这句话。
（1）低耦合：一个类对于本身依赖的类，知道的越少越好。不要让一个类依赖过多的类。不然这个类很容受外界的影响，而且由于这种影响要改变自身的代码（自身要适应）。
（2）高内聚：将实现逻辑都封装在类的内部，对public方法之外的信息，不轻易暴露给外界。这是因为public对外后，至关因而一种契约，一种许诺。你要再后边的实现中，不断的去兼容这种public，以防止调用它的代码不会报错。 上面这样说，可能有点抽象，这里举个例子。在不少人对另外一方的要求，都有一条，社会关系不要复杂。为何会这样呢？由于一我的若是他和外界的关系越复杂，他就越不稳定，不怕人找事，就怕事找人。或许他的本性是好的，可是周边的龙鱼混杂，三天两头的总会有事。避免这种问题的最好办法，就是一开始就作一个安静的美男子。
4）接口隔离原则
一个类对于另一个类的依赖应该创建在最小的接口上。
一个接口定义的过于臃肿，则表明他的每个实现类都要考虑全部的实现逻辑。若是一个类实现了某个接口，也就是说这个类承载了这个接口全部的功能，维护这些功能成为了本身的职责。这就无形中增长了一个类的负担。
这里有两点须要说明一下：
（1）接口定义的小，可是要有限度。对接口细化能够增长灵活性，可是过分细化则会使设计复杂化。同时接口的使用率不高，提升了代码的维护成本。这种极端的体现就是每一个接口只含有一个方法，这显然是不合适的。
（2）接口隔离原则和单一原则的区别
共同点：都是尽量的缩小涉及的范围。
不一样点：单一原则主要是指封装性。他针对的是一个类、一个方法，是从对象的角度考虑的。而接口隔离原则是指类之间的耦合应该保持的一个度。他针对的是类（对象）和类（对象）之间的关系。若是说单一原则指的是思想单纯，那么接口隔离指的就是社会关系简单啦。
5）依赖置换原则
这个原则的名字比较唬人，咱们先看看他的内容到底是什么。在设计模式中对该原则有两句经典的描述：
（1）高层模块不该该依赖底层模块。二者都应该依赖抽象。
（2）抽象不该该依赖细节，细节应该依赖抽象。
这两句话的含义是：高层模块不该该依赖底层模块。二者应该经过抽象的东西进行关系连接（抽象的东西是指接口或者抽象类）。其次抽象类或者一个接口不该该依赖某个实现类。而这些实现类反而应该依赖于这个抽象类的设定。
通俗一点的说法就是，模块之间不该该直接产生调用关系（这是旧有的调用关系），二者应该经过面向接口（或者理解为面向设定的契约）进行编程。而这些契约和接口更不该该以来自底层模块而设定。这些底层模块反而应该遵照这些契约。由于契约（抽象类、接口）相对于哪些实现代码，更不会改变，也就是更稳定。因此依赖置换原则又叫做面向接口编程或面向契约编程。本意就是调整原来的依赖关系，重行进行了设定。
6）开闭原则
开闭原则是指：一个软件、一套系统在开发完成后，当有增长或修改需求时，应该对拓展代码打开，对修改原有代码关闭。
类一旦肯定，就不该该再对其功能发生修改。这是面向对象设计中，最重要最核心的原则。方案发布后，咱们最担忧的是什么？就是需求的变化，而需求一旦有变化，就要修改代码。大部分的bug每每就是这时候引入的。由于修改代码时，咱们每每将重点放在，如何解决当前bug上，反而没有注意由于这个修改，对原有设计的影响。
这条原则没有具体的指导要求，是前边五条原则的根本。
ps，这六个面向对象的原则，并非是和否的问题，也不是遵照和不遵照的问题。而是遵照的多和遵照的少的问题。我在文中也屡次强调，咱们在设计时，应该注意把握一个度。诚然尽量的遵照这些原则，会使代码维护起来更容易。可是维护粒度过细，所须要的设计和开发成本成倍增长，这显然是舍本逐末的。如图，面向对象开发原则能够从如下这个坐标图展现，不管是哪一个维度，他的值都不该该过满，甚至溢出，固然也不能很低，保持一个适当的度便可。