sparrow 麻雀虽小，五脏俱全

为什么要写这个框架?

sparrow 源自中国俗语麻雀虽小，但五脏俱全，努力打造一个全新的低耦合，0依赖的高性能java 开发基础框架。这个框架我从11年开始写，中间重构了n遍，最原始的代码可能都找不到了，之所以坚持写，最初并不是想造新轮子。主要是从中学习基础原理。经过近十年的打磨，发现有些设计思想和理念，是值得学习的。比如spring mvc 的设计模式，orm ioc 等等。虽然很多朋友们都了解，但要真正自己实现起来也并不是那么容易。而这个过程对原来的深入理解是很帮助，所以将这部分开源出来，供有同样需求的朋友参考。在此过程中也发现了现有框架的一些弊端，比如没有一个跨数据源的orm。所有项目都需要依赖spring 才能跑起来，使我们的业务依赖很多jar，而大部分的jar包可能是不需要的，代码变得臃肿，维护困难。为此基于oop的基本思想，构建一层api,最大化的解耦。

为什么选择?

的slogon 是"创作你的创作",这个很有意思。所以想在作一个连载，和各位朋友交流框架的来龙去脉。

框架的设计哲学和概要

软件设计6大原则，这里推荐几本书，martin flower 的重构, 敏捷软件开发原则，模式和实践。

设计原则是软件设计的“魂”。是oop的基础，同样也是设计模式的基础，flower 说重构的目的是设计模式。

设计原则我总结一个单词solidi 比solid 多一个i

S (single)单一职责

这个原则是最重要，最简单，也是最难理解的原则。

小到一个方法，一个类，一个模块，大到一个jar 包，一个系统，一个生态，一个team都会涉及到这一原则，一个方法，为了保证方法的单一职责，并不是随意拆到最小不能再分为止，这样方法可能很碎，而是按需拆，原则就是能复用即可。要掌握好粒度，这个也是最难的地方。举个例子，架构源于建筑，砖头都是大小均等的，如果是不规则的石头和砖头相比，复用率就相对低很多。代码的复用是软件设计中非常重要的原则。那么代码复用就会带来一个问题，复用多了，必然就会耦合。那么解决耦合和复用的的指导方针就是单一职责。因为拆得尽量细，依赖自然少，复用也自然就多了。这句话需要点悟性。单体应用和分布式应用也涉及到拆的问题，这个话题，以后讨论。

O(open-close)开闭原则

写框架才发现这个原则有多么重要，尤其框架要考虑通用性，不会考虑个性化定制功能，但对于个性化的业务要做到兼容，这就是开闭原则。JDK 的spi 提供扩展点服务，框架中的具体代码，以后会和大家分享。spring 的ioc也实现了类似功能，核心思想就是oop 的多态。

l(Liskov Substitution)里氏替换原则

这个原则的意思就是父类可以由子类替换，继承是oop三大特性中的一个，非常非常的重要，但包括java编程思想中也提到少用继承，多用复合（代理也可以理解为一种复合)，其实这句话的核心语义，并不是不允许用继承，而是在强调一件事情，就是继承可能会重写父类的方法，而带来一些安全隐患，即子类可以改变父类的行为，这在软件设计被认为是不安全的，所以尽量避免用继承。包括java枚举，也是因为类型安全，其实用string也可以实现相同类型，但相对来说，不够安全。所以在我们设计方法时。尽量使用强类型，不要用map 和string 这种弱类型。这也是为什么jdk 的string 被设计成final 的其中的原因之一（为什么?）。包括后来阿里的代码规范，重写的方法一定要用override 关键字，也是这方面的考虑。

i(ioc)依赖倒置，控制反转

这个是老生常谈了，这是spring 要解决的根本问题，就是去掉代码中的new，因为new 这样的代码不够灵活，尤其工程很大的时侯想改一个功能，需要到处引用的地方全要改，成本很大，而ioc只需要相应的配置就可以了。

D(Demeter)迪米特法则

又叫作最少知道原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。

所以要确定哪些是陌生人，哪些是朋友

对于一个对象，其朋友包括以下几类：

(1) 当前对象本身(this)；

(2) 以参数形式传入到当前对象方法中的对象；

(3) 当前对象的成员对象；

(4) 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友；

(5) 当前对象所创建的对象。

用排除法，我们不难发现，其实说的陌生人就是指在方法内直接new 出来的对象（除pojo外)，要尽量避免，如果非要调用，可以使用工厂模式和facade框式。尽量解耦，降低类的使用权限，方法的使用权限，尽量最小化暴露方法和类也是该原则比较好的实践。所以private>protect>default (空)>public 方法，成员变量，和类都适用。

i(interface )接口隔离

这也是oop三大特性多态和抽象的实践，将抽象与具体实现隔离。使实现对上层业务透明，即将口的修改对上层业务不影响,该原则在框架中体现最为明显。包括log4j的接口设计和jcp 的标准化都是这一原则的最佳实践，所以sparrow也尽量不强依赖框架本身，只定义一些常用的标准化接口，并提供扩展点对调用方实现。sparrow-facede这个模块即接口定义。有兴趣的同学可以down源码，一起交流学习。

框架的的具体模块github 上有源码，在此就不多做介绍了

希望这一系列文章和源码对大家会有所帮助

下一步会逐步和大家交流框架的的一些模块的设计原理，谢谢

框架刚刚发布开源，还有一些bug 和不足在所难免，希望多提宝贵意见！

下载地址

https://github.com/sparrowzoo/sparrow

Sparrow 框架设计哲学