认识达内从这里开始

软件开发原则问题我们已经给大家在前几期的文章中多次强调了其重要性。尤其是不能违反用户的常规使用习惯。今天，我们就一起来了解一下，软件开发原则中的六个比较重要的原则都有哪些。

一、单一职责原则

1、单一职责定义

单一职责原则：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

单一职责原则告诉我们：一个类不能太“累”!在软件系统中，一个类承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其

他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。

2、单一职责优点

1)降低了类的复杂度。一个类只负责一项职责比负责多项职责要简单得多。

2)提高了代码的可读性。一个类简单了，可读性自然就提高了。

3)提高了系统的可维护性。代码的可读性高了，并且修改一项职责对其他职责影响降低了，可维护性自然就提高了。

4)变更引起的风险变低了。单一职责大的优点就是修改一个功能，对其他功能的影响显著降低。

二、里氏代换原则

这个和单一职责原则比起来，显然就好理解多了，而且也不那么模糊不清。

1、定义

官方定义：所有引用基类(父类)的地方必须能透明地使用其子类的对象。

简单理解就是：子类一般不该重写父类的方法，因为父类的方法一般都是对外公布的接口，是具有不可变性的，你不该将一些不该变化的东西给修改掉。

是不是感觉这个原则不太招人喜欢，因为我们在写代码的时候经常会去重写父类的方法来满足我们的需求。而且在模板方法模式，缺省适配器，装饰器模式等一些设计模式都会采用重写父类的方法。

怎么说呢，里氏代换原则的主要目的主要是防止继承所带来的弊端。

继承的弊端：

继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。

继承会增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。

三、接口隔离原则

1、定义

当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。

为什么要这么做呢?

其实很好理解，因为你实现一个接口就是实现它所有的方法，但其实你并不需要它的所有方法，那就会产生：一个类实现了一个接口，里面很多方法都是空着的，只有个别几个方法实现了。

这样做不仅会强制实现的人不得不实现本来不该实现的方法，严重的是会给使用者造成假象，即这个实现类拥有接口中所有的行为，结果调用方法时却没收获到想要的结果。

四、依赖倒置原则

1、定义

依赖倒置原则包含三个含义

1)高层模块不应该依赖低层模块,两者都应该依赖其抽象

2)抽象不应该依赖细节

3)细节应该依赖抽象

五、迪米特原则

这个原则在开发中还是非常有用的。

1、定义

大致意思是：即一个类应该尽量不要知道其他类太多的东西，不要和陌生的类有太多接触。

迪米特原则还有一个解释：Onlytalktoyourimmediatefriends(只与直接朋友通信)。

什么叫直接朋友呢?每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系类型有很多，例如：组合，聚合，依赖等。朋友类也可以这样定义：出现在成员变量，方法的输入输出参

数中的类，称为朋友类。

六、开闭原则

这个原则更像是前五个原则的总纲，前五个原则就是围着它转的，只要我们尽量的遵守前五个原则，那么设计出来的系统应该就比较符合开闭原则了，相反，如果你违背了太多，那么你的系统或许也不太遵循开闭原则。

1、定义

一句话，对修改关闭，对扩展开放。

就是说我任何的改变都不需要修改原有的代码，而只需要加入一些新的实现，就可以达到我的目的，这是系统设计的理想境界，但是没有任何一个系统可以做到这一点，哪怕我一直欣赏的spring框架也做不到，

虽说它的扩展性已经强到变态。

这个就不说了，字面上也能理解个八九分，它对我来讲太抽象。虽然它很重要。

作者：雨点的名字

节选：博客园

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!