设计原则在实际开发中的应用

什么是设计原则？

我们实际开发当中，经常会思考，"代码怎么写才是更好"这个问题，其实这个问题在有程序员这个工作的时候就已经出现了。前辈们也一直在思考，慢慢的提出了一些"好代码"的形容词。比如说：可扩展性，可读性，可维护性等。并且总结出了一些好代码的特点，这些特点就是现在所说的设计原则。也就是说我们遵从设计原则目的是开发出扩展性高，可读性好，可维护性强的代码。

设计原则有哪些

1. 开闭原则

对于扩展开放，对于修改关闭。这里是一个颗粒度的问题，一个动作到底是修改的还是扩展的，从不同的角度能得到不同的结果。这个原则是我们平时开发最常使用的，我们接手其他同事的代码，当有新需求变动时，都是在原代码的基础上进行改动的。个人认为，修改的源代码不影响原业务，并且是易于测试的都是遵守开闭原则。

2. 单一职能原则

同样的，单一职能原则也是有颗粒度的。实际开发中有同事会把一个业务的代码都写到一个类的一个方法当中，认为这个方法完成了这件事，他是单一职能的。但是一件事也可以拆分成很多个小事，每个小事也都是单一职能，这样看原来的一件事就不是单一职责了。所以在实际开发当中，需要我们合理的去拆分业务。

3. 里氏替换原则

里氏替换原则是面向对象当中特有的，它涉及到了父子类的关系。所有的父类都可以用子类去替换，并且保证原有程序的逻辑行为不变，并且正确性不遭受破坏，就是里氏替换原则。

4. 最小知识原则（迪米特法则）

最小知识原则在实际开发当中经常违反的，比如说a项目当中用了一个HttpUtil的工具类（一个开源的jar包），b项目是从a项目迁移过来但是不需要用到httpUtil的工具类，我们一般都不会删除这个jar包，其实此时就是违反了最小知识原则。还有就是在搭建项目的时候我们习惯把一些常用的东西都一次性导入进来，其实应该采用需要用什么导入什么，这样才是符合迪米特法则的。

5. 接口隔离原则

接口隔离原则指的是客户端不应该强迫依赖它不需要的接口。"接口"这个词，可以从不同的角度理解。比如微服务中的接口，如果a服务开放出来的接口在b服务中只调用了部分接口，那么此时应该将a服务中的接口隔离开来，让b服务只能看到自己需要的接口。接口隔离原则和单一职能原则有点类似，只是观察的角度或者说侧重的角度不同。他更加注重于接口的设计。

6. 依赖倒置原则

依赖倒置原则就是让框架帮助我们去控制流程，而不是程序员去控制流程。spring框架就是典型的依赖倒置原则的框架。

7. DRY原则

don’t repeat yourself。不要重复自己，也就是不要写重复的代码。注意代码是为了实现业务，如果是不同的业务即使代码重复了，也是不违反DRY原则的，不要过分的去抽象剥离代码。

如何写出符合原则的代码

没有人能一次性写出完美的代码，初次书写只能是大体符合，只有不断的去重构，才能写出更符合原则的代码。重构并不是说项目重新搭建，一点一滴的优化都叫重构，甚至于将错误的注释删除，并修改成好的注释都是重构。重构是随时随刻的在进行的，如果一旦有稍微大一点的改动，都需要书写单元测试，不然的后果可能是灾难性的。

如何编写单元测试

实际开发当中，写单元测试的人并不多。但是写单元测试绝对是一个好的习惯，这将决定着你代码是否能越写越好，目前阶段我个人认为只有易于测试的代码才能称得上是好代码，因为接受过几个别人的代码，每次再修改时都要补上基本的单元测试。单元测试也有不同的颗粒度，1.正常的数据逻辑，验证单元测试是否能通过。2. 边界值的单元测试。基本上做到第一点就可以了。如果能覆盖全边界值的单元测试，那只能说是优秀。测试不需要来给你提bug了。甚至你的公司已经不需要测试岗位了。