框架是： - 应用或子系统的设计
- 表示为：
- 一组抽象类和
- 这些类中对象的协作方法
用框架来创建应用通过: (编辑脚本) 逆向控制 子程序库 用户程序调用可重用的代码. 用户设计程序结构. 框架 重用代码调用客户程序 主要由重用代码(框架)决定程序结构 框架应用的部件 新的类使用组件的步组L 测试框架 类 - Test, TestResult, TestSuite 通过创建 Test的子类来使用。 定义 instance methods 来 配置、运行测试 定义 class methods 来建立一个测试单元 Model/View/Controller Classes - Model, View, Controller, ApplicationModel, ValueModel, etc. Use by using GUI builder to make a screen; the GUI builder automatically builds an ApplicationModel and a window-spec that later gets interpreted to build a window. HotDraw Classes - Figure, Drawing, Handle, Tool, DrawingEditor Subclass DrawingEditor, Figure, rarely Drawing Parameterize Handle, Tool. There is a graphical tool for defining new Tools. White-box vs. Black-box White-box 用户化通过定义子类强调继承 必须了解内部结构 设计简单容易 学习困难，需要更多的编程 Black-box 通过配置用户化 强调多态 必须了解接口 设计复杂、困难 学习容易，需要较少的编程 框架设计的第一规则 相关的原则 框架是抽象: 人们从实际的应用中归纳出来 设计重用的代码需要叠代 框架编码领域知识 框架的客户是程序员（译者：最终还是应用的客户） 从实际案例中归纳 人们思考是具体的，不是抽象的. 通过研究具体的例子抽象被彻底的发现 归纳: - 找出名称不同的相同事物,
- 通过参数化排除差异,
- 把大的事物分解成小的部分以发现类似的组件, 并且
- 分类相似的事物.
发现抽象类 抽象类的发现是通过归纳具体类. 定义类共有的SuperClass: - 定义操作的公共接口
- 把具有相同实现的操作转移到SuperClass
- 把实现不同的操作定义为抽象操作
(continued) - 定义公共接口（interface）
- 重命名操作使各个类有相同的操作名
- 重新排列参数、修改参数类型等.
- 重构 操作
框架需要迭代 能够重用的代码需要多次迭代. 软件工程基本规则 如果程序没有测试, 他将不能工作. 结论: 还没被重用的软件是不能重用的. 框架编码领域知识 框架解决特定的一组问题. Not always application-domain specific, but domain specific. (GUI, distribution, structured drawing editor, business transaction processing, workflow) 客户是程序员 框架的目的是更容易的构建应用. 适用这些标语为程序员: 客户总是正确的. 我们是客户驱动. 理解你的客户. 实例驱动的设计 归纳是迭带的. 小的改变是最多的. 少数大的改变代表看待问题的新方法. 更快的归纳: 开发框架的理想的方法 1) 分析问题域 - 学习众所周知的抽象.
- 收集用框架编写的例子程序. (最少 4 or 5).
设计框架的理想方法 2) 设计覆盖例子的抽象. 3) 通过编写这些例子来测试框架. - 每个例子都是相互独立的程序.
- 履行一个测试意味着开发一个软件.
抽象设计 设计阶段: 寻找共性, 描述每个想法. 用设计模式 灵活性和洞察力是有用的, 而且进展是困难的. 设计模式 设计模式使设计更接近黑盒. 怎样表示对象的变化 - Strategy -- 算法
- Prototype -- 产品
- State -- 对象的状态
- Mediator – 对象相互调用的方法
设计模式的使用 模式使设计更复杂. 模式使设计更有弹性. 你需要这种弹性吗? 这复杂性是否值得? 在两个模式中做选择时选择使设计更简单的. 为什么理想永远是理想 分析领域需求分析个别的例子,已经是非常困难的. - 即使例子已经被分析也仅仅实用.
- 分析和实现例子是工程的很大一部分成本.
- 人们需要汇集例子实现的反馈.
开发框架的好办法 精选两个相似的应用. 包括在相同领域有经验的开发者. 一个框架组 两个应用组 - 框架组
交换软件意见
考虑其他的应用
解释教受框架 - 应用组
尽力重用框架
抱怨框架如何难于使用
开发框架的典型方法 注意到许多应用是相似的. 用面向对象的语言开发领域中的下一个应用. 把软件划分为可重用和不可重用两部分. 开发下一个应用尽可能的重用可重用的部分. 惊奇! 框架的重用性不好. 修改. 开发下一个尽可能重用的软件. 重用的副作用 相互冲突的目标 重用的花费是昂贵的 坚持重用是困难的 重用的有利的一面 框架使用者利用框架开发者的经验. 仅增加有价值的特性. 帮助防止框架太复杂、太抽象. 另一种策略 定义框架 – 原形几个小的应用. 创建真实应用. 重构框架和老的应用. 过程摘要 以想得到的应用的例子开始 叠代的开发抽象 通过创建应用来测试 细节 1) 三个例子 2) White-box 框架 3) 组件库 4)热点（ Hot Spots） 5) 扁平化对象 (continued) 6) 平滑对象 7) Black-box 框架 8) Visual Builder 9) 语言工具 http://st-www.cs.uiuc.edu/users/droberts/evolve.html 应用产生器 Black-box 更容易: 用a picture描述应用 从 a picture产生代码 可视化编程语言使非程序员也能创建应用. 黑盒框架的缺点 黑盒框架趋向于有： - 更多种类的对象
- more artificial kinds of objects（真不知怎么描述？）
- 对象间更复杂的关系
- 更多对象
不完善的框架强迫你调试更复杂的系统. 模版和重构 重构 - 在不影响功能的情况下改变程序结构.
- 修改重用问题的方法.
- 创建一个弹性的 "hot spot"
- 经常应用一个模版
重构帮助发现组合 框架设计提示 用对象组合代替继承 多使用模版 /少泛化 框架应该打破限制 战略 开发框架是昂贵的,想清楚再做. - 框架开发需要长的周期.
- 好的框架能给你带来竞争优势.
从简单开始. - 有 OOP经验
- 选择训练好的抽象
- 先建一个小的框架
- 归纳已经存在的系统
- 起先保持小的用户群
客户是至关紧要的 进早的找到用户,并听取他们的反馈. 是你最初的客户成功. 最初的客户是开发小组的一部分. 重用的环节 现实: Projects may customize the initial framework, and start competing streams of development. 处理叠代 不要说框架是有用的除非你的客户这么说. 当框架演化时保持小的客户群. 一个成功的框架必须不断发展来适应新的用户需求. 不要不停的修补. 有计划的发布版本 并协调客户. 文档和练习 框架文档的价值在 重用的程序一定要是可理解的. 精练的文档使框架更重用. 文档以例子为基础. 文档和练习必须经过测试. Documenting system shows how to change it. Framework developers must be intimately involved. NIH vs. TILI Problem with reuse is NOT fault of customer. Software is not as reusable as it is claimed. It is hard to make software reusable. 可重用的设计是困难的 - 对于应用领域 框架必须是抽象并强大的
- 必须是可定制的对于用户
- 必须容易理解
|