框架设计基础

框架设计基础

 

一个成功的通用框架必须是为广大具有不同的需求、技能和背景的开发人员而设计的。框架设计师面临的最大的挑战之一就是为这些多样化的用户群提供既简单又功能强大的框架。

 

托管（managed）框架设计师的另一个重要目标，必定是为开发人员提供一个统一的编程模型，无论他们开发的是何种类型的应用程序，使用的是何种编程语言。

 

要设计既功能强大又易于使用的框架。

精心设计的框架使得实现简单的场景非常容易，但同时，它并不妨碍实现更为高级的场景，虽然这可能会更困难。正如Alan Kay所说的：“简单的东西应该是简单的，复杂的东西应该是可能的。”
本条规范也和80/20规则有关，即在任何情况下，20%是重要的，而80%则不怎么重要。在设计框架时，要把精力集中在那20%的重要场景和API上。换句话说，要把精力花在框架中使用最为频繁的部分。

 

要明确地为具有不同编程风格、需求、技能以及使用不同编程语言的开发人员设计框架。

要设计一个对Visual Basic程序员具有吸引力的框架，关键在于集中注意力帮助他们把不必要的麻烦降至最低，使他们能够迅速完成工作。在设计框架时，使用尽可能少的概念是个 不错的方法，这并非因为VB程序员不能处理概念，而是因为不得不停下手头的任务并考虑一些无关紧要的概念会打断工作流程。VB程序员的目标通常既不是学习 一些有趣的或是令人兴奋的概念，也不会被框架设计的纯洁性和简单性所打动，而是要完成工作并继续前进。

 

要了解那些使用多语言框架的广大开发人员

为那些与自己相似的用户进行设计会比较简单，而为那些与自己不同的用户设计则非常困难。太多的API都是由领域内专家们设计的，坦率地说，这些API只有对领域内专家而言才称得上好。
虽然著名的惠普格言“Build for the engineer at the next bench”（为身后的同事开发）对提高软件项目的质量和促使项目完成是有益的，但是它却会误导API设计。虽然这是显而易见的道理，但在设计API时我们往往会忘记这条原则。我们往往会只为自己设计API，而没有清楚地考虑用户的真正需求。

 

渐进框架

 

为广大的开发人员开发框架，使其支持不同的使用场景并适用于不同的编程语言，是一项高难度、高投入的事业。一直以来，框架供应商都针对不同的使用场景，为不同的开发团体提供不同的产品。例如，微软一方面提供一些Visual Basic程序库，这些库为简单性和一些相对狭窄的使用场景而优化；另一方面也提供一些Win32程序库，这些库为强大的功能和灵活性而优化，虽然这会牺牲易用性。而其他的框架，如MFC和ATL，同样也定位于特定的开发群体和特定的使用场景。

 

虽然在为不同的开发团体提供既功能强大又易于使用的API时，这种多框架的方法被证明是成功的，但它存在严重的缺点。主要缺点在于，多框架使得使用某个框 架的开发人员难以将他们的知识转移到下一个技能等级或使用场景（这通常需要另一个框架）。例如，如果开发人员需要开发另一个功能更加强大的应用程序，那么 它们会遭遇一条非常陡峭的学习曲线，这是因为他们不得不学习一种完全不同的编程方式。

 

在Windows的早期，我们可以使用Widnows API。要开发应用程序，只需打开C编译器，在源文件中加入#include <windows.h>，创建一个winproc，并处理Windows消息即可——这基本上就是老式的Petzold风格的Windows编程。虽然这样是可行的，但是它的开发效率不太高，开发起来也不太容易。

随着时间的流逝，出现了各种各样基于Windows API的编程模型。VB使用了快速应用程序开发（RAD）方法。用VB，我们可以创建一个窗体，拖放一个组件到窗体上，编写事件处理函数，而我们的代码则通过委托（delegation）来执行。

在C++中，MFC和ATL采用了另一个不同的角度。这里的关键概念是创建子类。开发人员会从一个已有的单一面向对象框架创建子类。虽然这给我们以更强大的功能和更丰富的表现力，但它的易用性和开发效率却远远不及VB编程模型。

而在用ASP进行Web开发时，我们看到了ASP模型的出现，在这种编程模型中我们编写的是内嵌在HTML页中的无状态的代码。

如果留意一下上面的描述，那么就会发现一个问题：编程模型的选择不可避免地决定编程语言的选择。这种情况是非常可惜的，因为对一个数量掌握MFC的开发人 员来说，如果需要在一个ASP页面中编写一些代码，那么他的技能无法被转化。同样，对一个非常了解VB的开发人员来说，也没有多少知识可以转化到MFC。

此外，还缺乏一致可用的API。以上各种编程模型实际上共同面临一些核心问题，例如，如何处理文件I/O，如何格式化字符串，如何处理安全性，如何管理线程等，而每一种编程模型都相应地提供了自己的解决方案。

.NET框架所做的就是把所有这些模型统一起来。无论开发人员使用何种编程语言或者选择何种编程模型，可供使用的API始终都是一致的。

 

一种更好的方法是提供一个渐进框架（progressive framework），它是为广大开发人员而设计的，使得开发人员能够从较低级的使用场景中积累知识，并应用到更高级的使用场景中去。

 

既要实现一条渐进的学习曲线，又要使门槛较低固然困难，但却并非不可能。其困难之处在于要在框架设计的过程中采用新方法，遵循更多的设计规则，并在设计上投入更多。

 

需要牢记的是开发人员社区的覆盖面非常之广，从使用宏的office用户到底层设备的驱动程序开发人员都包括在内。对一个框架来说，如果试图为所有这些用 户服务，那么其最终结果可能会是一团糟，甚至无法满足任何一个用户。渐进框架的目标是覆盖广大的开发人员，但并不是所有可能的开发人员。很明显，在此范围 之外的那些开发人员需要专门的API。