软件工程

本类阅读TOP10

·PHP4 + MYSQL + APACHE 在 WIN 系统下的安装、配置
·Linux 入门常用命令(1)
·Linux 入门常用命令(2)
·使用 DCPROMO/FORCEREMOVAL 命令强制将 Active Directory 域控制器降级
·DirectShow学习(八): CBaseRender类及相应Pin类的源代码分析
·基于ICE方式SIP信令穿透Symmetric NAT技术研究
·Windows 2003网络负载均衡的实现
·一网打尽Win十四种系统故障解决方法
·数百种 Windows 软件的免费替代品列表
·收藏---行百里半九十

分类导航
VC语言Delphi
VB语言ASP
PerlJava
Script数据库
其他语言游戏开发
文件格式网站制作
软件工程.NET开发
成功模式(pattern)作家的七个习惯(3)(by GOF)

作者:未知 来源:月光软件站 加入时间:2005-2-28 月光软件站

习惯三:开始时做得更具体(Being Concrete Early)

在我们的模式中,“意图”部分表现得更直接明了(up-front)。
这是因为人们对先提出具体的术语,然后才是抽象术语理解得
更好一些。“意图”部分的具体例子给读者一个问题的参考和
解决方案的框架。这个部分演示的另一个方面是为什么其它对
这个问题的解决方法失败了,同样用具体的术语。把“意图”
部分作为一个介绍,读者能更好的理解(appreciate)通用的解决
方案。

具体化的直接结果是需要从真实世界中来的大量例子。例子
不应该是“意图”部分所独有的财产。在整个模式中使用例
子和反例(counterexample)描绘了关键点。即使是我们模板
中最抽象的部分(如“适用性”,“结构”,“参与者”,和
“协作”)有时也有例子。举个例子,有些“协作”部分包括
表示对象在运行时怎样通信的交互图(interaction diagrams)。
在讨论模式的抽象部分参考这些例子---即是在你抽象时
也要具体点。

另一个直接结果可能是术语:“告诉别人整个真实情况”
(telling the whole truth)。这意味着你必须提醒你的
读者这个模式的潜在的缺点(pitfalls)。很容易对优点
部分喋喋不休;不容易理解它们的缺点并且真诚的谈论
这些缺点。没有一个模式是完全没有缺点的,或额外的
开销,或在特定环境下的不良表现的,等等。确保你的
读者懂得这个模式会有缺点(fall short)。


相关文章

相关软件