你知道如何写一个框架吗？详细步骤放送(1)(3)
总体设计
对 于总体设计我的建议是一开始不一定需要写什么设计文档画什么类图，因为可能一开始的时候无法形成这么具体的概念，我们可以直接从代码开始做第一步。框架的 使用者一般而言还是开发人员，抛开框架的内在的实现不说，框架的API设计的好坏取决于两个方面。对于普通开发人员而言就是使用层面的API是否易于使 用，拿我们的MVC框架举例来说：
最基本的，搭建一个HelloWorld项目，声明一个Controller和Action，配置一个路由规则让Get方法的请求可以解析到这个Action，可以输出HelloWorld文字，怎么实现？
如果要实现从Cookie以及表单中获取相关数据绑定到Action的参数里面，怎么实现？
如果要配置一个Action在调用前需要判断权限，在调用后需要记录日志，怎么实现？
我们这里说的API，它不一定全都是方法调用的API，广义上来说我们认为框架提供的接入层的使用都可以认为是API，所以上面的一些功能都可以认为是MVC框架的API。
框架除了提供基本的功能，还要提供一定程度的扩展功能，使得一些复杂的项目能够在某些方面对框架进行增强以适应各种需求，比如：
一 般而言如果要实现这样的功能就需要自己实现框架公开的一些类或接口，然后把自己的实现"注册"到框架中，让框架可以在某个时候去使用这些新的实现。这就需 要框架的设计者来考虑应该以怎么样的友好形式公开出去哪些内容，使得以后的扩展实现在自由度以及最少实现上的平衡，同时要兼顾外来的实现不破坏框架已有的 结构。
要想清楚这些不是一件容易的事情，所以在框架的设计阶段完全可以使用从上到下的方式进行设计。也就是不去考虑框架怎么实现，而是以一 个使用者的身份来写一个框架的示例网站，API怎么简单怎么舒服就怎么设计，只从使用者的角度来考虑问题。对于相关用到的类，直接写一个空的类能用接口 的尽量用接口，你的目的只是通过编译而不是能运行起来），让程序可以通过编译就可以了。你可以从框架的普通使用开始写这样一个示例网站，然后再写各种扩展 应用，在此期间你可能会用到框架内部的20个类，这些类就是框架的接入类，在你的示例网站通过编译的那刹那，其实你已经实现了框架的接入层的设计。
这里值得一说的是API的设计蕴含了非常多的学问以及经验，要在目标平台设计一套合理易用的API首先需要对目标平台足够了解，每一个平台都有一些约定俗成的规范，如果设计的API能符合这些规范那么开发人员会更容易接受这个框架，此外还有一些建议：
下一步工作就是把项目中那些空的类按照功能进行划分。目的很简单，就是让你的框架 的100个类或接口能够按照功能进行拆分和归类，这样别人一打开你的框架就可以马上知道你的框架分为哪几个主要部分，而不是在100个类中晕眩；还有因为 一旦在你的框架有使用者后你再要为API相关的那些类调整包就比困难了，即使你在创建框架的时候觉得我的框架就那么十几个类无需进行过多的分类，但是在将 来框架变大又发现当初设计的不合理，无法进行结构调整就会变得很痛苦。因此这个工作还是相当重要的，对于大多数框架来说，可以有几种切蛋糕的方式：
如果是一个RPC框架，大概是这样的结构：
对于我们的Web MVC框架，举例如下：
这里我们以IXXX来描述一个抽象，可以是接口也可以是抽象类，在具体实现的时候根据需求再来确定。
这 种结构的划分方式完全吻合上面说的切蛋糕方式，可以看到除了横切部分和分层部分，作为一个Web MVC框架，它核心的组件就是routing、model、view、controller、action当然，对于有些MVC框架它没有route部 分，route部分是交由Web框架实现的）。
如果我们在这个时候还无法确定框架的模块划分的话，问题也不大，我们可以在后续的搭建龙骨的步骤中随着更多的类的建立，继续理清和确定模块的划分。
经过了设计的步骤，我们应该心里对下面的问题有一个初步的规划了：
- 我们的框架以什么形式来提供如何优雅的API？
- 我们的框架包含哪些模块，模块大概的作用是什么？
用户点评