前言
聊到软件设计，首先可能要聊设计目的，一个软件为什么不能上来就开始写代码，为什么还要设计那，设计的目的是什么？设计的目的，其实是为了解决软件的复杂性，软件的复杂性体现在什么地方？不同的系统复杂性来源不同，有的软件，更注重性能，复杂性来源就是性能，有的讲究系统的高可用，高可用就是复杂性的来源，如果这两者都不讲究的软件，那多半是业务比较复杂，那就要求我们的软件具有很好的扩展性。
这就要求我们在进行软件的设计的时候，根据设计的目的考虑，注重分析现在的设计是否可以达到目的。设计也讲究个度，既不可以过度设计，考虑太多未来的东西，也不能考虑太少，有点像机器学习模型的训练，过拟合和欠拟合都不好。任何事务发展到一定程度，都具有一定的套路，形成一套理论和规范，设计也一样，有一些共性的方法，被前辈们抽象出来形成了设计原则和设计模式，二十多种设计模式，要想熟练掌握和应用，其实并不容易，个人觉得也没有必要，设计更重要的是要掌握原则，讲设计模式和设计原则的书很多，《敏捷软件开发 原则，模式与实践》
是绝对算的是其中的顶尖作品，这篇文章算是对其中的几点设计原则的一个总结，当然我不会照着抄，也不涵盖全，只聊最有意思的几个原则。
一 单一职责原则
所谓的单一职责，就是一个类也好，一个函数也罢，完成且只完成一个功能。有了这些单一职责的模块，很容易把软件像乐高积木一样地拼起来，每个模块的功能都是单一的。所以我们外界的变化多样的需求，无论怎么变化，对一个模块的影响比较小，我们只用调整不同的组装，即可完成我们的需求了。
单一职责还有个好处是复用性很好，如果一个模块的功能多了，那么在复用的时候，你只需要一个功能，却不得不附带另外一个功能，这样很容易引起bug。这就像我们买电器，只买必要的功能就可以了，没必要选择功能多的，功能越多，系统越复杂，反而越容易坏。
功能单一了也就比较容易测试，整个模块都只是这个功能的代码，没有其他功能的代码，整个模块的内聚性就很强，没有了功能与功能之间的耦合，耦合通过模块的组合来完成。所以单一职责原则强调的是高内聚和低耦合，用高内聚形来完成很好地复用性，而用低耦合的特性来应对外界的复杂与灵活。
按照单一职责原则设计的代码，在进行扩展功能的时候，只能通过扩展代码来完成，避免修改，而修改很容易引起bug，也不容易测试。
二. 依赖倒置原则
单一职责是强调一个模块，但是要组成整个系统，还必然需要将多个系统连接起来，就像刚才说的拼积木，我们要将整个系统都拼起来。拼起来的时候如果都是随意插拔，灵活性是有了，但是搭建出来的积木不稳定，况且这个搭建好的积木，要随着准备应对扩展功能的情况，系统的稳定性就更不好了，怎么办？ 对于一个软件系统来说，是上层（界面，用户接口）比较稳定那，还是下层（存储接口等）比较稳定，其实都不稳定，两者在现实的社会都会不断发生变化，所以无论下层代码依赖上层代码，还是上层代码依赖下层代码都不合适，被依赖的层不稳定，“软件”这个大积木，随时都会摇摇欲坠。解决方案其实也比较简单，那就是抽象出一层接口层，来涵盖上下层通信的复杂性，高层模块不依赖于底层细节编码，只依赖于接口层，而底层和上层之间通信，也是通过通用的接口形式。这样整体就相当于在一个架子上，去打积木，无论积木是增加还是减少，整个架子是稳定的，那整个系统就是稳定的了。
就拿Linux内核中的虚拟文件系统来举例子，linux下支持的文件系统有FAT，ext2，ext3，NFS等。如果每种文件系统和上层都通过不同的接口来对接，那么整个系统的维护复杂度就会很大，也不稳定，所以在Linux中抽象出一个文件系统VFS，它并不实现具体的功能，只是接口，
不同的文件系统实现这个接口就可以了如下图：
通过这个接口，隔离了下层的复杂的，上层不需要关注的细节，上层只要依赖于这个接口编程就支持了所有的文件系统，而底层的文件系统，也不需要关心上层的业务，只要关心接口需要实现什么就可以了，至于上层怎么使用，它并不关心。 从这个角度来说，接口算是一个约定，一个协议，大家都按照协议执行就可以了，一定可以对接的。
三. 抽象和细节
单一职责其实是一种细节的封装，为什么要封装，封装的目的很简单就是为了简化，这个世界太复杂了，我们为了理解，必须简化，简化就是一种抽象。举个例子，如果给你一堆零件去拼装一个汽车，这很复杂，但是，如果给你车身，车轮，等大部件来拼装个汽车要简单的多。因为车轮，车身这些都完成了封装，隐藏了复杂性，我们没有必要了解这些底层的细节，从而可以在更高的角度更轻松地解决问题。从更高的角度去观察，才可以发现很多大的明显的问题，如果沉入到细节之中，很容易忽略大问题，等发现这个问题的时候可能已经晚了。这给我的启示是， 在生活中，也不能太纠结于眼前。眼前相当于战术目标，而更远的未来才是战略目标，用更高的维度，更长的时间维度去看问题，会有不同的收获。
好了就聊的这里面了，最后强烈推荐这本书，真的很棒！
