软件设计的六大原则

开闭原则

对扩展开放，对修改关闭，即：在不改变原代码的状况下进行扩展。

任何软件都须要面临一个很重要的问题，即它们的需求会随时间的推移而发生变化。当软件系统须要面对新的需求时，咱们应该尽可能保证系统的设计框架是稳定的。若是一个软件设计符合开闭原则，那么能够很是方便地对系统进行扩展，并且在扩展时无须修改现有代码，使得软件系统在拥有适应性和灵活性的同时具有较好的稳定性和延续性。随着软件规模愈来愈大，软件寿命愈来愈长，软件维护成本愈来愈高，设计知足开闭原则的软件系统也变得愈来愈重要。

为了知足开闭原则，须要对系统进行抽象化设计，抽象化是开闭原则的关键。在Java、C#等编程语言中，能够为系统定义一个相对稳定的抽象层，而将不一样的实现行为移至具体的实现层中完成。在不少面向对象编程语言中都提供了接口、抽象类等机制，能够经过它们定义系统的抽象层，再经过具体类来进行扩展。若是须要修改系统的行为，无须对抽象层进行任何改动，只须要增长新的具体类来实现新的业务功能便可，实如今不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。

优势：实践开闭原则的优势在于能够在不改动原有代码的前提下给程序扩展功能。增长了程序的可扩展性，同时也下降了程序的维护成本。

体悟：开闭原则应当和单一职责原则联系紧密，只有一个类的职责足够少，才能作到尽量少的耦合，以达到在后期的扩展中，不会改变到原有的类

里氏替换原则

全部引用基类对象的地方可以透明地使用其子类的对象

里氏代换原则告诉咱们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，若是一个软件实体使用的是一个子类对象的话，那么它不必定可以使用基类对象。例如：我喜欢动物，那我必定喜欢狗，由于狗是动物的子类。可是我喜欢狗，不能据此判定我喜欢动物，由于我并不喜欢老鼠，虽然它也是动物。

例若有两个类，一个类为BaseClass，另外一个是SubClass类，而且SubClass类是BaseClass类的子类，那么一个方法若是能够接受一个BaseClass类型的基类对象base的话，如：method1(base)，那么它必然能够接受一个BaseClass类型的子类对象sub，method1(sub)可以正常运行。反过来的代换不成立，如一个方法method2接受BaseClass类型的子类对象sub为参数：method2(sub)，那么通常而言不能够有method2(base)，除非是重载方法。

里氏代换原则是实现开闭原则的重要方式之一，因为使用基类对象的地方均可以使用子类对象，所以在程序中尽可能使用基类类型来对对象进行定义，而在运行时再肯定其子类类型，用子类对象来替换父类对象。

优势：能够检验继承使用的正确性，约束继承在使用上的泛滥。

体悟: 这个说法相似面向对象中的多态，在使用中定义基类避免出现类型错误，在运行时在肯定其具体子类类型

依赖倒置原则

抽象不该该依赖于具体类，具体类应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

依赖倒转原则要求咱们在程序代码中传递参数时或在关联关系中，尽可能引用层次高的抽象层类，即便用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来作这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，不然将没法调用到在子类中增长的新方法。

在引入抽象层后，系统将具备很好的灵活性，在程序中尽可能使用抽象层进行编程，而将具体类写在配置文件中，这样一来，若是系统行为发生变化，只须要对抽象层进行扩展，并修改配置文件，而无须修改原有系统的源代码，在不修改的状况下来扩展系统的功能，知足开闭原则的要求。

优势：经过抽象来搭建框架，创建类和类的关联，以减小类间的耦合性。并且以抽象搭建的系统要比以具体实现搭建的系统更加稳定，扩展性更高，同时也便于维护。

体悟：利用抽象类下降类与类之间的耦合，用抽象类进行类之间的联系，改变某一类只须要改变抽象的接口，或者某一类的实现便可，不会改变原有类，利于扩展也利于维护。

单一职责原则

一个类只负责一个功能领域中的相应职责，或者能够定义为：就一个类而言，应该只有一个引发它变化的缘由。

单一职责原则告诉咱们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，并且一个类承担的职责过多，就至关于将这些职责耦合在一块儿，当其中一个职责变化时，可能会影响其余职责的运做，所以要将这些职责进行分离，将不一样的职责封装在不一样的类中，即将不一样的变化缘由封装在不一样的类中，若是多个职责老是同时发生改变则可将它们封装在同一类中。

单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，须要设计人员发现类的不一样职责并将其分离，而发现类的多重职责须要设计人员具备较强的分析设计能力和相关实践经验。

优势：若是类与方法的职责划分得很清晰，不但能够提升代码的可读性，更实际性地更下降了程序出错的风险，由于清晰的代码会让 bug 无处藏身，也有利于 bug 的追踪，也就是下降了程序的维护成本。

体悟：单一职责原则更有效的实现开闭原则，它使某一类的做用单一，有利于定位bug，更有利于类的复用和修改

迪米特法则（最少知道原则）

一个软件实体应当尽量少地与其余实体发生相互做用

若是一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽可能少地影响其余模块，扩展会相对容易，这是对软件实体之间通讯的限制，迪米特法则要求限制软件实体之间通讯的宽度和深度。迪米特法则可下降系统的耦合度，使类与类之间保持松散的耦合关系。

在将迪米特法则运用到系统设计中时，要注意下面的几点：在类的划分上，应当尽可能建立松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类形成太大波及。在类的结构设计上，每个类都应当尽可能下降其成员变量和成员函数的访问权限。在类的设计上，只要有可能，一个类型应当设计成不变类。在对其余类的引用上，一个对象对其余对象的引用应当降到最低。

优势：实践迪米特法则能够良好地下降类与类之间的耦合，减小类与类之间的关联程度，让类与类之间的协做更加直接。

体悟：迪米特法则就是下降耦合的意思

接口分离原则

使用多个专门的接口，而不使用单一的总接口，即客户端不该该依赖那些它不须要的接口。

根据接口隔离原则，当一个接口太大时，咱们须要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法便可。每个接口应该承担一种相对独立的角色，不干不应干的事，该干的事都要干。

在使用接口隔离原则时，咱们须要注意控制接口的粒度，接口不能过小，若是过小会致使系统中接口泛滥，不利于维护。接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。

优势：避免同一个接口里面包含不一样类职责的方法，接口责任划分更加明确，符合高内聚低耦合的思想。

体悟：相似于单一职责原则，只是更加细化，使接口也单一职责，这样在使用的时候，接口的复用性也会变高

六大原则 - 学习心得

六大原则中，开闭原则、里氏替换原则、依赖倒置原则 联系比较紧密，后二者是实现开闭原则重要前提，使用中经过抽象化设计具备很好的可拓展性和可维护性。

知道最少原则 能够下降耦合，减小没必要要的交互，主张设计接口和类要简单易使用，将复杂的逻辑封装并提供简单易用的接口。

单一职责原则 使项目中的类和方法根据职责细分，避免单个类负担太重。职责越多，被复用的可能性就越小或使用起来越麻烦。

接口分离原则 将功能复杂的接口细分红多个特定功能的接口，只作该作的事情，下降耦合，可是细化粒度不能太细，容易致使接口过多。单一职责原则强调单个类内部根据职责细分的设计，接口分离原则强调类之间的耦合，尽可能创建最小的依赖关系。

注释：我的以为，单一职责原则和开闭原则联系最为紧密，依赖倒置原则是开闭原则比较重要的部分，知道最少原则却是一种思想，最终要达到的效果是开闭原则。