高级程序员必会的程序设计原则 —— 普适性原则

前言

当我们开始准备创造一个伟大的项目时，势必会考虑到未来的扩展性，希望能够成为一个通用的解决方案来解决一类问题。从定制到通用，从特殊到一般的转变需要先从抽象层面去寻找不同项目的共性并提炼它们。

简记

一个模块在解决相同或类似需求时，它不应只局限于或受制于上层模块，应当可以很容易的被其他上层模块或其他项目引用。

如何让一个模块普适化

图1、让程序普适化可以与具体实现解耦

比如我们在编写一个文本编辑器时，需要考虑打开一个文本文件，并自动判断它是gb2312编码还是utf-8编码，这段程序可能一开始会耦合在我们的业务代码中，入参也许是TextBox（文本框）、EditorContext（上下文）、OpenFileDialog（打开文件对话框）。这便要求了自动推断编码的这段程序只能放在当前项目里，当我们需要复用该模块时，要么下个项目也用同样的入参、构造其上层模块，要么就只能把入参改为String或者byte[]，然后用上层对象的getText()或readAllBytes()之类的方法来耦合我们改造好的模块。

既然我们在做第二个项目的时候总是要改这个模块，为什么不在一开始写的时候就让这个模块只依赖编程语言自带的对象呢？

都说“众口难调”，我们在这里调的就是各个模块的“众口”。

有些时候我们可以通过定义恰当的参数列表来完成普适性。而有些时候我们可以通过依赖某个公共类、增加回调函数、添加生命周期钩子的方式来协调不同项目对相同模块的要求。

为了能够让模块更加普适，我们不一定非要让模块更加复杂，也许反而我们可以让它更简单一些，比如依赖接口开发而不是具体实现、像大多数JSON框架一样引入泛型机制，因此普适性和复杂度某种程度上并不具备相关性。

功能上，如果A模块比B模块判断的场景更多、功能更丰富，那么A模块便会比B模块更通用。如果一个模块是可配置的，那么配置式模块的普适性一定会大于约定式模块。

关于究竟是约定大于配置还是配置大于约定，在业内有过很激烈的讨论，但至今没有结论。这是因为二者都是为了实现普适性，但站的角度不同而已。约定大于配置会假定各方都是如此，没有必要显式声明，从而实现各种项目普适化的敏捷。配置大于约定会假定各方的情况都不一样，需要明确配置项，从而实现各种项目普适化的需求。

毕竟“小孩子才会做选择，成年人全都要”。如果既要普适化的敏捷又要完成普适化的需求，则一个很好的案例可以学习Spring框架，它用多套各自平行又能相互融合的解决方案解决了这一问题。我们可以深入地配置（比如XML、properties、yml或者写Class）、也可以只需遵守约定（比如注解）。

为了能够实现普适性，我们可以采用以下几种方法：1、使用配置文件，让模块可以通过配置来适应不同环境。2、使用上下文或参数化对象来适配不同需求。3、添加枚举或常量，并在恰当的地方让用户可以自行选择模块的行为。4、进行适当抽象或采用面向接口的方式开发。

但也要注意的是，普适性原则关注的是通用模块、平台模块，而非业务领域模块，如果我们非要在业务上做普适性，根据复杂度守恒原则，我们没有办法让得到普适性的模块更加纯粹，这便会导致平台内聚效应，底层平台的功能愈发强大，而我们在实现业务的层面没有得到任何的提升，只是增加了复杂性，但现实中由于架构师经验丰富，便容易因为恐惧而徒增了大量的普适性适配，因此好的架构应当是桶状结构，而非金字塔结构。它带来的另一个问题便是如果模块通用度极强，可以完成相当非常复杂的实现，但我们经常显而易见的简单功能，它却很难完成，我们不得不显式的排除各种干扰因素，使之符合一个明确的预期。

图2、正金字塔型架构等于大炮打蚊子，倒金字塔型架构等于产品皆仅供演示

总结

当一名程序员开始考虑如何让手头的项目进行普适化改造时，他不知不觉中便开始进入了架构设计领域。一个好的软件架构其实是一种高度普适化的产品，它可以用来解决一类问题或称为跨越各行各业的通用解决方案。但当项目还未成型时过早的去普适化项目，会成为拖累项目进展甚至导致项目失败的一个重要原因。所以时机应当选择在项目结束以后，花费不少于项目研发的时间去做普适化，一个公司的技术积累其实就是用普适化了多少模块和产品来衡量的。但由于有些单位和企业做项目比较浮躁，因此就会呈现出做一个项目扔一个项目的现象，项目结束了便不再投入资源去凝练它，不仅白白浪费了研发人员的工作成果，更是浪费了社会资源。而我们作为研发人员唯一能做到的就是，如果接手了前人的项目，先不要着急全盘否定它，而是试图去增强和优化它，只有做到足够长时间的沉淀，项目才会成为产品，产品才会成为技术。