写框架思路进程（二）

开搞

1、取名，考虑易读、易写、易记，也需要尽量避免和市面上其它产品的名字重复，还有就是最好不要起一个侮辱其它同类框架的名字以免引起公愤，我们只是代码的搬运工，而不是愤青。

2、项目相关域名

3、找地方托管代码，本地源代码仓库和远程网络的异地仓库

总体设计

不一定需要写什么设计文档画什么类图，因为可能一开始的时候无法形成这么具体的概念，我们可以直接从代码开始做第一步。框架的使用者一般而言还是开发人员，抛开框架的内在的实现不说，框架的API设计的好坏取决于两个方面。对于普通开发人员而言就是使用层面的API是否易于使用，拿我们的MVC框架举例来说：

1、最基本的，搭建一个HelloWorld项目，声明一个Controller和Action，配置一个路由规则让Get方法的请求可以解析到这个Action，可以输出HelloWorld文字，怎么实现？

2、如果要实现从Cookie以及表单中获取相关数据绑定到Action的参数里面，怎么实现？

3、如果要配置一个Action在调用前需要判断权限，在调用后需要记录日志，怎么实现？

API，不一定全都是方法调用的API，广义上来说我们认为框架提供的接入层的使用都可以认为是API，所以上面的一些功能都可以认为是MVC框架的API。

框架除了提供基本的功能，还要提供一定程度的扩展功能，使得一些复杂的项目能够在某些方面对框架进行增强以适应各种需求，比如：

1、Action是否可以返回图片验证码？

2、Action的参数绑定是否可以从Memcached中获取数据？

3、如果出现异常，能否在开发的时候显示具体的错误信息，在正式环境显示友好的错误页面并且记录错误信息到数据库？

一般而言，如果要实现这样的功能就需要自己实现框架公开的一些类和接口，然后把自己的实现“注册”到框架中，让框架可以在某个时候去使用这些新的实现。这就需要框架的设计者来考虑应该以怎么样的友好形式公开出去哪些内容，使得以后的扩展实现在自由度以及最少实现上的平衡，同时要兼顾外来的实现不破坏框架已有的结构。

在框架的设计阶段完全可以使用从上到下的方式进行设计。也就是不去考虑框架怎么实现，而是以一个使用者的身份来写一个框架的示例网站，API怎么简单怎么舒服就怎么设计，只从使用者的角度来考虑问题。对于相关用到的类，直接写一个空的类（能用接口的尽量用接口，你的目的只是通过编译而不是能运行起来），让程序可以通过编译就可以了。你可以从框架的普通使用开始写这样一个示例网站，然后再写各种扩展应用，在此期间你可能会用到框架内部的20个类，这些类就是框架的接入类，在你的示例网站通过编译的那刹那，其实你已经实现了框架的接入层的设计。

API的设计蕴含了非常多的学问以及经验，要在目标平台设计一套合理易用的API，首先需要对目标平台足够了解，每一个平台都有一些约定俗成的规范，如果设计的API能符合这些规范，那么开发人员会更容易接受这个框架。建议：

1、之所以我们把API的设计先行，而不是让框架的设计先行，是因为这样我们更容易设计出好用的API，作为框架的实现这，我们往往会进行一些妥协，可能会为了在框架内部DRY而设计出一套丑陋的API让框架的使用者去做一些重复的工作；也可能会因为想让框架变得更松耦合，强迫框架的使用去使用到框架的一些内部API来初始化框架的组件。如果框架不是易用的，那么框架的内部设计再合理又有什么意义？

2、尽量少暴露一些框架内部的类名吧。对于框架的使用者来说，你的框架对他一点都不熟悉，如果上手你的框架需要学习一到两个类尚可接受；但如果要使用到是几个类就会头晕脑胀，即使你的框架有非常多的功能以及配置。可以考虑提供一个入口，比如创建一个ConfigCenter类作为入口，让使用者可以仅仅探索这个类便可对框架进行所有的配置。

3、一个好的框架是可以让使用者少犯错误的，框架的设计者务必要考虑到，框架的使用者没有这个义务来按照框架的最佳实践来做，所以在设计API的时候，如果你希望API的使用者一定要按照某个方式来做的话，可以考虑设置一个简便的重载来加载默认的最合理的使用方式，而不是要求使用者来为你的方法初始化一些什么依赖，同时也可以在API内部做一些检测，如果发现开发人员可能会犯错，则进行一些提示或抛出异常。

4、API应有一套统一的规范，比如入口叫XXXCenter或者XXXManager，而不是叫XXXCenter、YYYManager或ZZZService。API往往需要进行迭代和改良的，在首个版本中把名字用掉也不一定是一个好办法，最好还是给自己的框架各种API的名字留一点余地，以后要升级换代就方便些许。

把项目中那些空的类按照功能进行划分，让你的框架的100个类或接口能按照功能进行拆分和归类。

1、分层。框架和应用程序一样，也需要进行分层，分层是横向的分割。框架和应用程序一样也需要进行分层。传统的应用程序我们分为表现层、逻辑层和数据访问层，类似的对于很多框架也可以进行横向的层次划分、我们的框架要处理的问题是基于多层抽象的，就像如果没有OSI七层模型，要让一个HTTP应用去直接处理网络信号是不合理也是不利用重用的。

举例：写一个基于Socket的RPC的框架，我们需要处理方法的代理以及序列化，以及序列数据的传输，这完全是两个层面的问题，前者偏向于应用层，后者偏向于网络层，因此把我们的框架分为两个层面的项目（至少是两个包），rpc.core和rpc.socket，前者不关心网络实现来处理所有RPC的功能，后者不关心RPC来处理所有的Socket功能，在将来即使我们要淘汰RPC协议了，我们也可以重用rpc.socket项目，因为它和RPC的实现没有任何关系，它关注的只是socket层面的东西。

2、横切。横切是纵向的分割（横切是跨多个模块的意思，不是横向来切的意思）。横切的关注点就是诸如日志、配置、缓存、AOP、IOC等通用的功能，对于这部分功能，我们不应该他们和真正的业务逻辑混淆在一起。对于应用类项目是这样，对于框架类项目也是这样，如果某个部分的代码量非常大，完全可以为它分出一个单独的包。如，对于RPC项目，我们可能会把客户端和服务端通讯的消息放在common包内，把配置的处理单独放在config包内。

3、功能。要实现一个框架主要解决的问题点，如上面提到的RPC框架的core部分，我们主要解决的是客户端如何找到服务端、如何把进行方法调用以及把方法的调用信息传递给目标服务端、服务端接受这样的信息后如何根据配置在本地实例化对象调用方法后把结果返回给客户端这三大问题，那么可以把项目分为routing、client、server等几个包。

下一篇文章，会根据RPC框架进行结构上的分析，来推出我们的Web MVC框架。