初看题目好像是将编程规范的，其实是编写框架的规范，而且不是一般的应用框架，而是像.Net这样级别的大框架，书中的专家也都是亲身开发.Net框架的专家，说论述的例子也都是.Net框架的例子。这么一看好像和我们没多大关系，但看了几章觉得其中学问挺大，虽然我们也许永远不会去开发这种级别的框架，但是鉴戒之处还是颇多，如果我们设计的程序都与.Net框架的标准一样，想不优异都难。
我会随着阅读深入慢慢总结，当然只限于个人认为重要的东西，泛泛的千篇一律的东西就不写了。（评：为什么书名不把框架二字翻译出来FrameWork Design Guiderlines，简直是误导读者，就像把Code Complete翻译成代码大全一样，真不知道这帮人干啥吃的）
1，在开发过程中，如果进度压力太大，特性蔓延太快，或太想满足各种小而极端的需求，那么就经常会牺牲简单性。但是简单性是每一个框架必备的品质。如果某个设计的特性比较复杂需要再三考虑，那么将该特性从当前版本中去除，然后到下一个版本投入更多的时间得到适合的设计往往更好。
2，框架设计的基本原则
场景驱动设计的原则
我们给框架设计师的建议是，从用户的角度，先自己编写一些对主要场景来说必不可少的代码，然后再设计对象模型（object model）来支持这样样例代码。这与测试驱动开发（TDD）或基于用例的开发过程相似，它们之间的区别是，TDD更为重量级，它不仅仅是帮助API的设计，用例的场景比API调用的场景更大。（我：这句话的中心思想是从上而下的设计，由使用者决定我们应该编什么样的类什么样的方法，什么为参数，如何通信等等。测试驱动也是这个意思，只不过它是一个完整的用例，比API的场景更大一些而已）
与之相反，框架设计师常犯的错误就是一开始设计对象模型，然后根据得到的API编写样例代码。这样做使设计的具体实现更容易维护，而不是为了使API更容易使用。也许做内部架构设计这种方法还可以，对大型框架的公用API却并不适合。
（评 ： 内部框架也完全可以从上到下设计啊，不见得就不易维护啊，还不是一样，但使用起来使多么优雅）
CHRIS ANDERSON 一开始就编写设计者希望开发人员编写的代码几乎就是最好的方法－－可以认为是某种形式的驱动开发。设计者先编写完美的代码，然后在回过头来得出自己想要的模型。（评：英雄所见略同，呵呵）
3 主要场景的API应该只需尽可能少的初始化，理想情况下，如果类型是为基本场景设计的，那么使用默认的或者自带一个简单参数的构造函数应该就可以开始工作了。（评： 提供简单的构造函数，提供多样的构造函数）
4 要尽可能为所有的属性和参数提供合适的默认值。默认值要避免使程序退化的默认值。
5 要通过异常来传达对API的误用,异常消息应当清楚的告诉用户如何解决该问题。
6 为广大的开发人员构建单个框架的一般规范是：把API划分成低层类型和高层类型，让低层类型暴露丰富的API并提供强大的功能，而高层类型则用便利的API对低层API进行封装。（评： 注意这里高层和低层代表的意思，我的理解是高层更面向某一具体应用，而低层更一般和广泛，比如注重开发效率和简单性而优化的API为高层，功能强大多样化的为低层）
ASP.Net是一个例子，ASP.Net 为那些需要强大功能和丰富表现力的开发人员提供了一个低层的HTTP层，虽然它提供的抽象非常少，但它允许开发人员直接处理发往Web服务器的请求。ASP.Net同时还提供了一组丰富的Web控件，使开发人员不必操心Web协议就能通过属性和方法处理高层的概念。（评：有此看出，高与低并不是说抽象程度而是易用与灵活性高低的程度，二者显然反比）
