《软件工程实践者的思想(PDF格式)》第21章

Aspect　关注于“有相似需求的考察对象”的群体特性。其　
相似性在群体中表现得越广泛，则　AOP 的优势也就越明　
显。例如在　Delphi 的　VCL　框架中，以下两个需求就可以　
① 人们在争论Aspect　到底应该译成“切面”还是“方面”这件事上　
花了很多功夫。其实，就如同讨论前面的“关注点”究竟是“点”　
还是“线”的问题一样，他们陷入了细节。如果这些细节被作为　
问题持续下去，那么可能有一天台海战争将不是发生在军队之间，　
而是在程序员之间：到底是“物件”，还是“对象”？
② 在C　中，这个名词是“结构（Struct）　”。很多人不会承认“对象是　
有继承关系的记录”这样的观点。是的，所有的教科书上都不会　
这样写。但是从数据结构本身以及数据结构在语言中的实现来看，　
对象终究是记录。记录是平板化的内存存储体系中所能表达的最　
复杂的单一数据体。
…94
…………………………………………………………Page　99……………………………………………………………
『大道至简』
用　AOP 的思想来实现：
） 使　Delphi 中的全部对象具有多线程特性（　即线程　
安全）　；
） 实现助手工具类以观察、控制　Delphi 对象的运　
行期特性或表现。
到现在为止，我们弄清楚了　AOP　作为“思想、方法、　
工具”的一些基本知识，以及它的应用范围：至少你要明　
白，他是用来考察对象（而不是设计对象）　的思想方法。
所以接下来　AOP 的三个概念我们就明白了：
） 指示（advice）/拦截器（interceptor）　：考察这些对象　
以“达到什么样的目的”（　即需求）　；
） 引导（introduction）　：在目标上实现这些需求时，　
目标所需要表现出来的公共特性。引导特性可能　
需要配合编译器来实现。
） 元数据（metadata）　：如果需要，为既有对象实体　
再补充一些参考数据。
确切的说，切分点（Pointcut）并不是　AOP 编程方法所　
需要的概念，而是　AOP 作为一个框架时所需要的一个工　
具：一组辨识　Acpects　和　Objects 的索引。
现在你已经会用　Acpect 的思想来编程了，而无论它　
是用　Java 来实现的，或者是用　C#　、Delphi　，乃至于　
FORTRAN　或　COBOL　。你需要做的是，回到工程最核心　
的那个环节：编程＝算法＋结构＋方法。
…95
…………………………………………………………Page　100……………………………………………………………
第　7　章 现实中的软件工程
5。 审视　MDA/MDD
MDA（Model Driven Architecture）　也是一个方法论层　
面上的名词。它讨论的是“创建出机器可读和高度抽象的　
模　型　”　的　方　法　。　受 MDA 影　响　的　开　发　活　动　被　称　为　
MDD（Model　Driven　Development）　。
与　MDD　在同一个层面上的概念是：
） TDD（Test　Driven　Development）
） FDD（Feature　Driven　Development）
） BDD（Business　Driven　Development）
） R…TDD（Rapid　Template…Driven
Development）
） CDD（Contract　Driven　Development）
） RDD（Requirements　Driven　Development）
） 。。。
我不厌其烦地罗列这些名词，只想告诉读者一个事　
实：什么都可以“驱动开发”。
不同的方案提供商基于自己的产品构架和当前的理　
论倾向，随时都在准备改变他们“驱动开发”的方式。在　
这种形势下的 “xDD　”或“xDA　”，已经成为他们促销产　
品的保留用词。
回到软件工程的过程环节中来吧，你会看到，“以什　
么驱动开发”只是一个“以哪个环节为中心（或导引）　”的　
问题。所以你会看到　TDD 中的　X　模型（也可参考　V　模型）　
是这样的：
…96
…………………………………………………………Page　101……………………………………………………………
『大道至简』
如果你仍旧不能明白为什么会有这么多被神秘力量　
所“驱动着的开发”，那么你就干脆去厨房找个平底锅烧　
点热油，然后敲下一个鸡蛋，很快，你就体悟“以蛋黄驱　
动开发”的真谛了。
抛开实现的技术细节不论，在工程中，“以什么驱动　
开发”其实是一个过程问题。而你应该明白，过程的选择　
（或制定）取决于你的工程需要，以及它在相关应用领域的　
适用性、过程工具的充备性和这个过程理论的完善程度，　
而不是大公司们的鼓吹。
过程模型决定了工程的实施步骤和组织方式。但是　
Object　Management　Group　（OMG） 尽管对　MDA　提出了一　
套完备的技术和方法体系，工程实施者却无法在这个体系　
中找到一个可以适用的软件过程模型。——MDA 不讨论　
过程。
…97
…………………………………………………………Page　102……………………………………………………………
第　7　章 现实中的软件工程
也就是说，MDA 架构作为一个新的软件开发方法的　
架构，即使在技术研究、底层协议和软件实现方面经过了　
持续地完善而渐至成熟，然而如果没有同样成熟的软件过　
程理论支持，那么它在工程中的实用价值也就有限。
仔细审视一下这个　MDA　，如果你现在就决定将下一　
个工程项目建立在这个构架的基础上，或者用　MDD 的方　
式来开发　BIOS　，那么你离精神病就不远了。
…98
…………………………………………………………Page　103……………………………………………………………
第8章 是思考还是思想
“此郎亦管中窥豹，时见一斑。”
——《晋书·王献之传》
1。 软件工程三个要素的价值
思考问题的方法可以是由点及面的，也可以是统揽全　
局的。换成业界最常用的词汇，就是“自上而下”还是“自　
下而上”的区别。
“牛屎图”中描述的工具、方法与过程也被称为软件　
工程的三个要素。在本书中他们被分解开来思考，并不是　
要孤立这个三个层面。——它们实际上是相互作用的。
例如“过程”问题，就既有实施过程的工具，也有相　
关的过程方法理论。我虽然说方法是“基于一种数据结构　
的编程实践的结果”，但这实在一种非常狭义的定义。这　
个定义在过程的开发环节是有效的（或者说是对“开发方　
法”的定义）　。然而“需求”、“设计”、“测试”等等其它　
环节也有各自的方法论，即使站在具体环节之外，过程本　
身也有方法论的问题，这还不包括管理方法等等在内。
由于方