手写Java框架（一）-----理想的开源框架与设计原则

理想的开源框架
•她应该是小的、简单的，满足Simple Is Beautiful

•她应该是成长性好的，随着不断的扩展，她可以越来越丰满

•她应该是有良好工具支持的，为什么要花时间做工具可以完成的事情呢？

•她应该是自组装的，也就是尽可能的脱离配置，而是用一种依赖即可用，取消依赖即消失的全自动处理模式

•她应该是模块化的，所有的内容都可以被打入jar包而作为一个整体进行发布，并且能支持热部署的，可以开着车儿换轮胎的

•她应该是支持水平部署的，想加服务器就加，想减服务器就减

•她应该是有良好知识积累体系的，使得使用框架的人们越用越强，越用越爽

•她应该是便于企业降低开发成本的，便于技术经理控制开发进度的，便于开发人员快速上手的

•她应该是避免重复劳动的，所有软件参与者都不应该做重复的事情

•她应该是自管理的，最好不要让程序员配置这个配置那个

•她应该是让人有种"众里寻他千百度,蓦然回首,那人却在,灯火阑珊处”的开发框架

按照这个目标去设计
•虽然整体体量比较大，但是它的每个模块都分得非常小，因此非常容易掌握

•它的各种组件都可以方便的进行扩展，通过扩展可以不断的提升系统的处理能力

•它的工具已经非常强大，而且它还是变得更加强大。

•不管是管理台还是过滤器、Servlet，不管是流程组件还是UI组件，还是UI组件包等等都是可以自组装的

•Web工程只是个集合，除了配置文件和Pom依赖，不应该有其它东西

•支持水平扩展，同时可以支持7*24小时运行

•开始团队由金字塔向哑铃型转变，高低水平者各司其职

•绝大多数情况下，要做的只是依赖，而不需进行配置

这样去打造框架——设计原则梳理

 COC原则：

Rails 中很少有配置文件（但不是没有，数据库连接就是一个配置文件），Rails 的fans号称期开发效率是 java 开发的 10倍，估计就是这个原因。Maven也使用了CoC原则，当你执行mvn
-compile命令的时候，不需要指源文件放在什么地方，而编译以后的class文件放置在什么地方也没有指定，这就是CoC原则。

 DRY“不要重复自己”原则

对于做重复的事情一向是深恶痛绝的，因此非常不原意开发人员在基于Tiny框架进行开发时出现重复的内容。为此Tiny框架在设计上做了大量的工作，来避免程序员做违反DRY原则的内容

DRY——Don't RepeatYourself Principle，直译为“不要重复自己”原则^_^

DRY简而言之，就是不要写重复的代码。原则本身很简单，但是，对于OOAD来说，有着非常重大的意义。

DRY利用的方法就是抽象：把共同的事物抽象出来，把代码抽取到一个地方去。这样就可以避免写重复的代码。

举一个DRY的典型例子，如果在一个类构造的时候，需要进行成员的初始化，在进行了某些操作以后，同样要进行初始化，那么就可以把“初始化”抽象出来，做成一个方法Initial()，在构造和需要用到的地方调用它。

虽然，抽取重复代码是利用DRY的一个好的开端，但DRY的实质是，一个需求，用一个部分来完成。当你试图避免重复代码的时候，实际上，你做的应该是用一段代码来完成一个需求。

为什么要用DRY原则？DRY会给代码维护带来很大的好处。以类的初始化为例，假设类修改了，增加、减少或是修改了成员，如果不写Initial()，那么你可能至少要修改两处，而且，修改之处也可能出现不一致，维护成本大大增加。而写了Initial()方法，那么只要集中修改Initial()就行了。

既然DRY是关于“一个方法，实现一个需求”的，那么，是不是可以把DRY应用到需求分析中？呵呵，答案是肯定的，而且，个人认为，这是个非常好的主意。多个重复的需求可能导致多个重复或者相近的类，最后导致重复代码。所以DRY绝不仅仅对代码适用，它是一个广泛适用的原则

   减法原则

    意思就是给程序员做减法。一般来说越到底层的程序员，工作时间越短、技能越弱、经验越少。但是实际工作当中，你会发现越到底层的程序员要做的事情越多，要用的技能也越多。这也是现在程序员工作效率低、质量差的重要原因。因此我们认为应该给程序员做减法，越到底层的程序员做的事情要越单一、越简单。

下级服从上级原则

框架则从框架层级做了限制，使得下级必须服务上级。这两点主要体现在流程及页面实现中，上级经理可以对下级完成的工作内容进行强制性要求实现，不同的是流程是采用显式继承的方式，而页面是隐式继承的方式