腾讯工作13年之所思所想，那些优秀程序员的共性特征
👉导读
👉目录
01
02
03
04
05
06
07
08
我们与框架作者之间的关系是非常不对等的。我们要采用某个框架就意味着自己要遵守一大堆约定，但框架作者却完全不需要为我们遵守什么约定。 请仔细想想这一关系，当我们决定采用一个框架时，就需要完整地阅读框架作者提供的文档。在这个文档中，框架作者和框架其他用户对我们提出进行应用整合的一些建议。一般来说，这些建议就是在要求我们围绕着框架来设计自己的优秀的系统架构。譬如，框架作者会建议我们基于框架中的基类来创建一些派生类，并在业务对象中引入些框架的工具。框架作者还会不停地催促我们将应用与框架结合得越紧密越好。 对框架作者来说，应用程序与自己的框架耦合是没有风险的。毕竟作为作者，他们对框架有着绝对的控制权，强耦合是应该的。与此同时，作者当然是非常希望我们的应用与其框架紧密结合的，因为这意味着脱离框架会很困难。作为框架作者来说，没有什么比让一堆用户心甘情愿地基于他的框架基类来构建派生类更自豪的事情了。换句话说，框架作者想让我们与框架订终身-这相当于我们要对他们的框架做一个巨大而长期的承诺，而在任何情况下框架作者都不会对我们做出同样的承诺。这种婚姻是单向的。我们要承担所有的风险，而框架作者则没有任何风险。 解决方案是：请不要嫁给框架! 我们可以使用框架-但要时刻警惕，别被它拖住。我们应该将框架作为架构最外圈的一个实现细节来使用，不要让它进入内圈。 如果框架要求我们根据它们的基类来创建派生类，就请不要这样做，我们可以创造一些代理类，同时把这些代理类当作业务逻辑的插件来管理。 另外，不要让框架污染我们的核心代码，应该依据依赖关系原则(DIP)，将它们当作核心代码的插件来管理。以 Spring 为例，它作为一个依赖注入框架是不错的。也许我们会需要用 Spring 来自动连接应用程序中的各种依赖关系。这不要紧，但是千万别在业务对象里到处写 @autowired 注释。业务对象应该对 Spring 完全不知情才对。反之，我们也可以利用Spring将依赖关系注入到 Main 组件中，毕竟 Main 组件作为系统架构中最低层、依赖最多的组件，它依赖于 Spring 并不是问题。