代码规范| 面向对象六大基本原则

开闭原则

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。任何软件都需要面临一个很重要的问题，即它们的需求会随时间的推移而发生变化。当软件需求变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化. 软件实体(类、模块、函数等等)应该可以扩展，但是不可修改。

我们在设计软件的时候，首先要搞清楚程序当中什么是未来可能变化的，什么是未来不会变化的。对于可能变化的东西，我们要提前给与可以对应的扩展接口。当然实际开发中，即便是我们认为这些不会变化的地方，未来还是可能变化的，这种变化就只能改代码了，但是这种修改仅仅只是改变个别细节，整体架构往往不会变化。而对于可能变化的地方，我们要给出可以足够扩展的空间，让其能够自由扩展，基本发生了重大的需求变更，整体架构也不会受影响。

开闭原则对于开发框架、可以被复用的组件（如jar、dll、js插件等待）尤为重要，因为这些组件必须留出足够的空间去让调用者去扩展自己的业务。所以我们在开发这种组件的时候api才是最难设计的，因为我们设计的api必须能满足调用者对他的全部扩展，这样才能实现调用者在不修改组件代码的情况下实现自己的需求。

里氏替换原则

所有引用基类的地方必须能透明地使用其子类的对象，也就是说子类可以扩展父类的功能，但不能改变父类原有的功能。程序将不会产生任何错误和异常，反过来则不成立从面相对象的角度来说，里氏替换原则是子类可以替代父类，但是从面相组件的角度看，其实是确保组件的api是完整的、不变的，子类和外界也是完全解耦的，只有这样我们开发出的扩展才能在不破坏原有框架的基础上运行。

依赖倒置原则

高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。简单的说就是尽量面向接口编程.依赖倒置就是让各个对象耦合度降低，高层模块不能继承底层模块，需要底层的东西也是外界注入而不是自己创建得到；同时调用的时候也是使用接口调用，而不是依赖具体实现，并且因为是接口调用，具体实现模块可以被任意替换了。这样做就可以降低各个模块的耦合，也可以确保里氏替换原则的实现。实现里氏替换原则有什么用？当然是可以方便扩展了。

单一职责原则

概念：就一个类而言，应该仅有一个引起它变化的原因。一个模块（接口）的功能尽量是单一的，这样不同功能的接口就不会耦合在一起了，同时维护起来也方便。就像计算器程序，其中有加法的运算类、减法类、乘法类、除法类。如果没有封装成这个四类，这4种运算算法混在一块，修改其中一个的时候能影响到其他的算法。所以必须拆分成四个类分别实现不同的算法；

接口隔离原则

客户端不应该依赖它不需要的接口；每个类继承的接口一定要保存最少，不能继承无用的接口一个类对另一个类的依赖应该建立在最小的接口上。接口最小化,过于臃肿的接口依据功能,可以将其拆分为多个接口。

保证接口隔离原则的前提是先要保证职责单一原则。

迪米特原则

一个对象应该对其他对象保持最少的了解(发生相互作用。),简单的理解就是高内聚,低耦合，一个类尽量减少对其他对象的依赖，并且这个类的方法和属性能用私有的就尽量私有化。

总结

六大原则中，最重要的肯定就是开闭原则了，我对开闭原则的理解是，你无须在每个细节上都要做到对扩展开放，对修改关闭，而是应该为了面对扩展而扩展。当有这种需求的时候，例如一个项目业务、算法可能会有重大的变化，或者本身开发的就是一个组件，这是才需要扩展，而扩展的时候才应该使用设计模式来实现这种需求，也就是说使用设计模式和我们平时开发一样，都是满足需求。使用了设计模式不一定能真正地提高代码的结构和可维护性，所以有经验的程序员会按需求而使用设计模式。六大基本原则可以更好地帮我们如何分析，这样才能确定是否使用设计模式。事实上设计模式的使用上我建议无招胜有招，满足项目的额外需求（例如利于扩展、可复用、高可维护性）都是好招，无需管他是什么设计模式。