|
这个主题共有 21 回复 ／ 2 页 [
1 2
下一页
]
|
|
|
|
|
|
致面向对象技术初学者的一封公开信
|
发表: 2007年01月25日 14:55
|
回复
|
|
致面向对象技术初学者的一封公开信
Alistair Cockburn 著（1996 年2 月），袁峰 译
介绍
首先我要解释一下为什么会写这封公开信。这似乎已经成了一种习惯，但这个步骤还是需要的。过去6 年中， 我曾经无数次地在饭店、酒吧、旅店大厅等各种地方以同一种方式度过愉快而漫长的夜晚：和同样追求真理、光明和智慧的伙伴一起探讨面向对象的真谛。现在，我已经可以回答很多当年我遇到的问题。这些同样的问题也在困扰着我的一位新同事，在一家饭店里，我花了整整一个晚上和他讨论这些问题。结果第二天，他的同事又来问这些问题，并建议把我们的谈话内容记录下来，这样他可以拿去给他的同事看。考虑到还有很多和他的同事一样询问这些同样问题的人，我决定写下这篇文章。
主要的问题是：
z 为什么只要稍有一点不是严格或纯面向对象的做法、说法，OO 专家就大惊小怪的？use case 并不是面向对象的，为什么还这么流行？而且，OO 建模似乎和数据建模非常相似？
z 数据建模（data model）得到的模型和对象模型的结构部分会不会很像？流程建模（process model）和对象模型的行为部分呢？
z 业务结构建模中为什么要用use case 和场景（scenario）?
OO 的新手们反复问这些问题，但实际上，只有在日常工作中坚持应用面向对象的思维进行工作，积累一定的经验，才能得到满意的答案。为什么只要稍有一点不是严格或纯面向对象的做法、说法，OO 专家就大惊小怪的？use case 并不是面向对象的，为什么还这么流行？而且，OO 建模似乎和数据建模非常相似？
我想分三步来回答这个问题。
首先，我举我和Bob（著名的OO 专家）一起工作的例子， 当我们讨论OO 的时候，彼此都有一个共识，知道对方拥有面向对象工作的丰富经验并且是这项技术的坚定支持者。而且，对诸如对象识别（object identity）、多态、数据和行为的封装、实例职责、继承等对象技术都是手到擒来。因此，当我说：“明天对程序表单进行数据建模吧”，Bob 不会产生我要会因为关系表而放弃对象这样的误解，他知道我指的是在对象模型中体现出来的结构化特性进行建模。他知道我会说些什么，因此我使用或误用这些术语不会造成什么误解。但作为一个对象技术的初学者，如果Bob 发现你把数据和行为完全分离开了， 并且没有使用（ 或者说忽视了）对象识别或者多态等技术， 这时候， 如果你说“ 数据建模”，Bob 会像一堵墙一样逼近你，直到你明白该怎样改变。这样工作几个月，你会发现，你的模型（以及建模）中渐渐有了对象识别、多态、数据和行为的绑定，这时候再用“ 数据建模”这个词就不是那么危险了， 但Bob 还可能会担心你走回到老路上。换句话说， 他对你还不够信任， 因此，你不得不很小心地使用这些术语。
就算一个对象模型可以分为“结构”和“行为”特性，我们也不会使用“对象建模”和“流程建模” 这种术语，以免引起混淆。事实上，为对象模型的“结构”特性建模可以看成是数据建模的特殊形式，只不过建模的对象不再是表，而是需要捕获的信息的结构。我们将它称为“ 概念数据模型”，而不是逻辑数据模型或物理数据模型。第二步，让我们考虑两个OO 使用者一起讨论的情况。如果其中一个家伙说到“流程建模”这样的词，肯定会让他的拍档琢磨半天：这家伙是说用标准数据流图作流程建模吗？如果这样的话，以后OO 实现的时候不是相当麻烦了吗？他是不是指模型的行为特性？是不是说在一个对象内部对流程进行建模？（如果这样的话，那会很有意思，因为很少有人这么做的。） 通过这个例子我们可以看到，这种谈话中使用“ 流程建模” 这种意图不明的词实在是太危险了，很容易就将交流变得非常困难。
最后来说use case 和场景的问题，它们都是获取需求的主要手段，和实现技术无关。其好处是可以为设计时的讨论提供内容和范围。它们不是“面向对象”的，这是事实，它们类似于功能分解，这也是事实，而且这一点吓坏了很多人，但这些都无所谓。重要的是它们为设计提供了内容，在用来描述内部设计时，它们表现了系统的行为。Flow chart 、交互图、Petri 网、数据流图、use case 都可以用来描述系统的行为特性， 但各自用途不同，各有优劣。关键是要知道：对象不仅有数据，也有行为， 认识到这一点， 就可以大胆地去考虑怎样可以更好地捕捉、描述对象内部和对象之间的行为。
数据建模（data model ）得到的模型和对象模型的结构部分会不会很像？流程建模（process model） 和对象模型的行为部分呢？根据我的经验，数据建模人员可以分为两种－一种是为存储的数据建模，而另一种是为系统或组织中的信息建模。这两者截然不同。前者讨论和思考所用的概念通常都很具体，比如说数据表。他们的模型和OO 建模者的模型大相径庭，而且他们并不愿意看到这些技术之间的相似性。在数据建模社区中，只有讨论逻辑数据模型或物理数据模型才不会受到攻击后者得到的是概念数据模型。根据我的经验，他们得到的模型和那些有经验的OO 建模者得到的模型非常相似。他们的工作更加类似于业务人员，而不是逻辑数据建模人员，这种说法可能会有助于理解概念数据模型和逻辑数据模型的区别。
似乎有一套学问可以帮助人们比OO 建模人员更快地得到结果。我多次发现这样的事实：OO 建模人员花了三四次迭代才得到的模型，实际上和（概念）数据建模人员一个循环得到的模型是一样的。这个发现使我对数据建模人员充满了敬佩。事实上，在进行对象设计的时候，我有时就直接去把数据建模人员的产品拷贝过来看看， 从中来看我最后得到的模型大概会是什么样的。
我曾经召开过数据建模人员和对象建模人员之间的会议。采取的方法是“ 一个听众的CRC 会议（CRC sessions for an audience）。四个经验丰富的OO 设计师坐在长桌一端，业务专家沿着长桌坐下，他们负责回答问题并纠正对业务的误解。接着是数据建模人员，长桌的另一头是其它有关人员。总的来说，屋里大概是十几个人，但谈话主要是在四个OO 设计师之间进行。
讨论大概一个小时之后，OO 设计师可以得到对象设计的一部分。这时候，咨询数据建模人员，这个模型和他们已经得到的模型本质上是不是一样的。他们说，“是的”，重复这个过程两次以上，每次都询问数据建模人员同样的问题，除了使用的符号技术是不同的，例如：他们没有用继承，但在同样的地方有同样的占位符，在本质上，这个模型和他们的模型没有什么不同的。接着，我们分成几个小组，每个小组包括一个业务专家、一个数据建模专家和一个OO 专家，很快就剩下的设计达成一致，找出技术上一些小的不同之处，并且进行排序。一般情况都是这样的：要么数据建模人员考虑得更加合理，要么OO 建模人员考虑得更加合理，小组要做的是在他们的设计之间进行协调。
从上面的这些经验可以看到，使用CRC 进行OO 建模得到的模型和概念数据建模得到的结果非常相似。另外，根据经验，基于逻辑（存储的信息）的关系建模和OO 建模是不同的。大多数情况下，区别是由于技术的不同导致的，例如，在OO 模型中可以自由地使用继承和多对多的关系。由于技术上的差异，两种建模人员之间不能很好地交流，这是最大的困难。
数据建模部分的问题就说这么多吧。
|
|
|
|
|
|
致面向对象技术初学者的一封公开信(2)
|
发表: 2007年01月25日 14:56
|
回复
|
|
对流程建模而言， 情况却不一样了。90 年代初， 涌现出各种方法、计划、会议和项目，试图将数据流图的模型转变为对象模型。曾经有几个项目声称获得了成功，但都是后续无音，业界一致的结论是： 这个转变太困难了。大多数使用数据流图的建模人员最终都抛弃了这项技术， 投入了对象设计的怀抱（Martin-Odell 和Ptech 小组是著名的例外）。对于流程建模，现阶段我的回答是：其模型无法与OO 模型相比较。但这并不是最终的回答，OO 建模人员正在开始进行本质上的流程建模，下一步的发展将会怎样，我也并不清楚，流程将变成过程那样（过程编程复活？）， 或者变成数据流图那样，还是类似于封装的对象？
业务结构建模中为什么要用use case 和场景（scenario）?
use case 和场景……
……为讨论提供范围和内容，
……预示内容，包括什么，不包括什么，讨论多广，多深入，什么时候停止，
……为设计的压力测试提供参数。
我见过一些不使用“场景”的小组，他们建模的时候实际上就是在问题域内作随机的探险。负责人根本不知道下一个该问什么问题？经常都是凭直觉。一般说来，他们也不知道现在捕获的信息最后是否真正需要，就算知道也是凭直觉或者瞎蒙。
在一个寂静的深夜，几个真正专家级的OO 设计师向我说了心里话：根本就没有一个有效的规则来指导漂亮的对象设计。其中一位说，“我们有时真的是在毫无目的地讨论”， 另一位也相当赞同，“有时候我们就象没头的苍蝇一样到处乱撞，直到突然把一些好的对象给撞出来。”
使用场景也不能防止盲目的讨论和到处撞墙，只是可以为讨论提供内容和边界。我曾经见过有的小组不用场景，长时间在很大的建模范围内四处乱撞，失去控制。因此，使用场景和use case 的第一个理由就是为建模的努力提供一个范围。
使用场景的第二个理由是决定需求获取到什么程度算足够。
假设现在让你为一家货运公司建模。你建模的内容是什么？卡车的购买价值……实际价值……转售价值……车内颜色……快送单据的数目……旅途的数目和目的地？如果你想要把所有的内容都包括进来，那你将永远无法结束。除此之外，还有其它的问题：从何处开始，何时结束，包括什么，不包括什么，需要多少细节？ 场景可以回答关于内容的问题，答案是：你需要足以回答场景中所有问题的信息。在结构化模型或完全的对象模型中，如果用一个方框来对应一个场景。然后在浏览场景的过程中将涉及到的元素（译者注：这里的元素， 是比如在OO 的类或对象） 涂成红色， 会发现最后所有的元素都按某种顺序连接起来了（不会有遗漏的元素）。如果对所有的场景都执行这个操作，最后所有的元素都会被涂成红色。在建模过程中，讨论会经常离题，用这种方法可以保证针对当前的需要制定一个边界，这样不会跑题太远。
最后，场景还提供了压力测试的参数以保证质量。
怎样比较两个模型的优劣？ “和业务相符”，这是必要的，但肯定不够，可能有很多模型都可以“和业务相符”，怎样来度量这些模型的质量呢？
软件变更的成本很高，另外，变更越靠后，变更的成本也就越高。（变更成本曲线）。软件设计的一个目的就是将变更隔离开来，每次变更只需改变一个模块。这并不是什么时候都能做到的，正如Kent Beck 所说，“如果你可以只改变一个类， 那软件的质量将得到显著的提高”。和软件相比， 业务模型的成本函数并不是很清楚，但将变更影响的范围降低到最低肯定是应该的。
为了测试变更曲线，需要参数，而场景可以提供这些参数。如果用户想要“something-or-the-other”，怎么办？模型中到底需要多少元素？像CRC（class-responsibility-collaborator ）这样的技术鼓励用户在现场快速得到场景， 揭示可能的未来变更。最后，检查这些可能的变更，检查需要为之改动多少元素。对于两个都“和业务相符”的模型，哪个模型受场景影响的点少一些，哪个模型就要好一些。其它很多地方也可以找到压力测试的参数。例如相关产品的结构，变更时是不是可以只改一点就可以了？在评价模型时，这些参数都应该用上。
场景还可以用在很多地方，例如：同用户一起检查需求，为系统提供功能测试的用例。以上所说，就是在建模活动中采用场景的三个理由。
[该贴被litdong于2007年01月25日 14:56修改过]
|
|
|
|
|
|
re:致面向对象技术初学者的一封公开信
|
发表: 2007年01月25日 15:19
|
回复
|
|
23种设计模式
7种结构型模式 + 11种行为模式算是对"数据建模"和流程建模提供了技术实现上的借鉴.
|
|
|
|
|
|
re:致面向对象技术初学者的一封公开信
|
发表: 2007年01月25日 15:20
|
回复
|
|
|
|
|
|
|
|
re:致面向对象技术初学者的一封公开信
|
发表: 2007年01月26日 09:47
|
回复
|
|
|
这是给初学者看的吗？还不如就实际小模块，写点面向对象的分析过程，逐步引导一下
|
|
|
|
|
|
re:致面向对象技术初学者的一封公开信
|
发表: 2007年01月26日 10:51
|
回复
|
|
主要反映了96年当时OO国外刚刚发展起来的一些困惑，对目前中国现状非常有借鉴意义。
关于文中谈到的“数据建模”，搞OO的人最反感别人谈数据两个字，更别说关系数据库了，这就像我在J道呼吁：数据库时代已经终结一样，因为关系数据库对大家影响太深入了，几乎是到骨子里。
这种现象在中国更加普遍，凡是搞企业软件的，数据库概念已经熔化到他的血液中，直至影响了他的软件思维，应用软件和数据库软件是两个不同概念，企业软件是应用软件，而不是围绕数据库的软件的，这也是我呼吁：数据库时代赶快终结的原因。
数据库时代的终结
http://www.jdon.com/artichect/dbover.htm
旧的时代结束，必然有新的时代和思想替代，96那个时候，oo体系思想还没有形成，所以作者在该文中概叹了这样的苦恼，现在10年后的今天2007年已经完全不同，Evans 2004年发布的 领域驱动设计 DDD，就是一个对象建模的经典巨著，他的作用不亚于GoF 设计模式在OO体系的重要性。
Evans DDD我已经对之有系统介绍：
面向对象与领域建模
http://www.jdon.com/mda/modeling.html
所以，今天我们再来看这篇公开信，感概OO体系来之不易，不是某个天才的灵感，可以说是多少人几十年探索的结果，现在我们很多程序员使用java或.NET这样OO语言还在开发非OO程序，传统的过程数据库软件，在落后生产技术上走那么长时间还不醒悟？
莫哀大于斯了！
|
|
|
|
|
|
re:致面向对象技术初学者的一封公开信
|
发表: 2007年01月26日 11:33
|
回复
|
|
|
|
|
|
|
|
回复:re:致面向对象技术初学者的一封公开信
|
发表: 2007年01月29日 16:19
|
回复
|
|
|
|
|
|
|
|
回复:回复:re:致面向对象技术初学者的一封公开信
|
发表: 2007年01月30日 11:50
|
回复
|
|
|
|
|
|
|
|
回复:致面向对象技术初学者的一封公开信
|
发表: 2007年02月01日 10:09
|
回复
|
|
|
|
|
|
|
|
re:致面向对象技术初学者的一封公开信
|
发表: 2007年02月07日 22:09
|
回复
|
|
相关帖子：
一个不上进程序员的困惑:
http://www.jdon.com/jive/thread.jsp?forum=16&thread=30877
该文作者列举自己只懂业务，对Struts、hibnerate jdbc，ejb，jboss好像只懂皮毛，感觉自己废了，其实这正是他认识偏差。
他现在这样状态是对的，是符合Evans提出软件人员只需要关心业务的软件发展目标，他无需对软件具体技术平台了解太多，他需要加强DDD建模认识，将有限精力集中在建模这个创新过程上，这才发挥人的特点，而不是成天被动学习，需要创造才会有作用。
板桥大哥，十分同意你的看法，我这段时间找工作，发现公司的招聘都是列出一堆一堆的技术，但是真的一个开发人员，那些只做业务开发的开发人员，为什么要精通这些技术呢，了解就足以，这些技术是平台开发人员关心的。国内的软件公司都是这个样子，给人感觉很浮躁。
|
|
|
|
|
|
re:致面向对象技术初学者的一封公开信
|
发表: 2007年02月08日 12:48
|
回复
|
|
板桥大哥，十分同意你的看法，我这段时间找工作，发现公司的招聘都是列出一堆一堆的技术，但是真的一个开发人员，那些只做业务开发的开发人员，为什么要精通这些技术呢，了解就足以，这些技术是平台开发人员关心的。国内的软件公司都是这个样子，给人感觉很浮躁。
是啊，框架的东西，我现在认为只是调用调用人家的API而已，我希望学点不变应万变的那种内功
|
|
|
|
|
|
回复:致面向对象技术初学者的一封公开信
|
发表: 2007年02月14日 10:37
|
回复
|
|
|
|
|
|
|
|
回复:致面向对象技术初学者的一封公开信
|
发表: 2007年02月19日 09:57
|
回复
|
|
针对近期有些网友认为面向过程的系统有相应快，效率高的特点，打算采取面向过程和OO混合的开发。
我的观点如下：谁说面向过程快？汇编语言是最初语言，更快呢！现在双核运行以前basic更快，在这种情况下，追求性能快已经没有意义。
效率高也不对，只能说第一次迭代时开发效率高，但是随着你对系统认识深入，开发效率就越来越慢，合起来算效率高？这里反映我们的脑子思维出问题了，以为软件开发是一锤子买卖，一次开发就搞定，这反映年轻人猴急不成熟心态。软件是有生命的，是随着我们对需求的深入理解，不断进行开发维护，采取OO会越开发越快。
面向过程和OO是一对矛盾，不能并存，一旦并存，就是怪胎，系统一无是处。现在我们的软件系统70%都是这样混血儿系统，使用Java/.NET/RoR这样对象语言，实现面向过程编程，结果系统不是性能慢，就是开发效率差，然后睡不着觉怪床歪，埋怨OO，更多原因是自己没有完全杜绝面向过程和数据库编程思维，没有完全走上OO思维。
OO思维本很简单，大道至简，非常符合我们日常人类思维，那么为什么那么多人读了软件书和培训后（面向过程的培训），以一种自以为专业却很别扭甚至畸形的方式来做软件，当告诉他们做软件可以用OO这样简单自然时候，他们反而用异类眼光看你，实在不行了，采取中庸主义，面向过程和OO混合可以吧？这些人不知道思维方式的跳跃式和矛盾性。
http://www.jdon.com/jive/thread.jsp?forum=46&thread=30987
|
|
|
|
|
|
re:致面向对象技术初学者的一封公开信
|
发表: 2007年02月19日 10:24
|
回复
|
|
>针对近期有些网友认为面向过程的系统有相应快，效率高的特点，打算采取面向过程和OO混合的开发
这个本来就是一种错误的理解，就像系统写的好不好跟采用的方法没有关系，面向对象跟面向过程都是分析方法而不是实现
>谁说面向过程快？汇编语言是最初语言，更快呢！现在双核运行以前basic更快，在这种情况下，追求性能快已经没有意义。
banq老大，这样比较没有意义吧，我说大机的效率比pc高，这样说有意义么？？你用p4双核跟我的286进行PK这样还有什么意义？？而且老大你把软件的意义狭隘了，现在很多工业设计对时序要求十分严格，否则就会产生错误，比如医疗系统，如果一个时序出错，就会要了病人的命。
汇编语言现在就没有市场了么？？为了提高速度，我们经常做系统分析找到系统最慢的部分，然后进行改进，如果实在不行，我们真的使用汇编嵌入的方式。单独的某个方法使用汇编会影响这个的系统设计么？？
|
|
|
|
|
|
这个主题有 21 回复 ／ 2 页 [
1 2
下一页
]
|
|
|
注册
登陆
上一主题
下一主题
