冒号论坛 » Tag: abstraction

冒号论坛 » Tag: abstraction - Recent Posts http://bbs.zhenghui.org/tags/abstraction 冒号论坛 » Tag: abstraction - Recent Posts en-US Fri, 10 Sep 2010 03:27:07 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://bbs.zhenghui.org/search.php hui on "UML感想" http://bbs.zhenghui.org/topic/uml%e6%84%9f%e6%83%b3#post-183 Thu, 02 Sep 2010 15:21:54 +0000 hui 183@http://bbs.zhenghui.org/ 一元思维是刚性的，多元思维是柔性的。 Todd on "UML感想" http://bbs.zhenghui.org/topic/uml%e6%84%9f%e6%83%b3#post-182 Thu, 02 Sep 2010 14:36:40 +0000 Todd 182@http://bbs.zhenghui.org/ 佛教里面最大的一部经《华严经》讲宇宙是多元的，以前不懂，现在从UML中受到启发，似乎有点儿明白了。 Todd on "需求与设计的关系" http://bbs.zhenghui.org/topic/%e9%9c%80%e6%b1%82%e4%b8%8e%e8%ae%be%e8%ae%a1%e7%9a%84%e5%85%b3%e7%b3%bb#post-168 Tue, 03 Aug 2010 08:50:10 +0000 Todd 168@http://bbs.zhenghui.org/ SICP上提到：与任何复杂系统一样，分层(Hierarchy)是一种应对软件复杂性的组织方式。 hui on "需求与设计的关系" http://bbs.zhenghui.org/topic/%e9%9c%80%e6%b1%82%e4%b8%8e%e8%ae%be%e8%ae%a1%e7%9a%84%e5%85%b3%e7%b3%bb#post-167 Tue, 03 Aug 2010 00:06:21 +0000 hui 167@http://bbs.zhenghui.org/ 关于软件开发的过程（暂不考虑软件测试和维护）一般的说法（以waterfall模型为代表）是：分析用户需求 => 提炼出合乎需求的规范 => 根据规范进行设计 => 编写代码实现设计。这种描述过于粗线条了，实际的开发过程往往是上层需求产生下层设计，在实现该设计的过程中又产生更下层的需求...正是你上面所描述的情形。不出意外地，在这里我们又看问题的关键仍然是：如何将复杂的问题合理地进行抽象分层。 Todd on "需求与设计的关系" http://bbs.zhenghui.org/topic/%e9%9c%80%e6%b1%82%e4%b8%8e%e8%ae%be%e8%ae%a1%e7%9a%84%e5%85%b3%e7%b3%bb#post-166 Mon, 02 Aug 2010 19:29:59 +0000 Todd 166@http://bbs.zhenghui.org/ 最近在学习TDD的过程中，我对需求与设计的关系进行了一些思考，我发现：系统A的需求决定了A的外部特征，这是系统A不变的部分；系统A的设计是如何将A划分为有关联的若干子系统a1,a2...an，这就是系统A的可变部分；系统A的设计又转化为对其子系统a1,a2,...an的需求。如果把视野扩宽，系统A的需求也必然产生于更大的系统中的设计。所以，软件需求是来源于更高层次的设计的。对于软件来说产品设计处于最高层，产品设计来源于对用户需求的理解（可能并不明确，需要自己探索）。 hui on "UML感想" http://bbs.zhenghui.org/topic/uml%e6%84%9f%e6%83%b3#post-157 Sun, 11 Jul 2010 10:47:31 +0000 hui 157@http://bbs.zhenghui.org/ 说得很好，这是一个普适的结论，不仅适用于软件系统，也适用于一切认知对象。 Todd on "UML感想" http://bbs.zhenghui.org/topic/uml%e6%84%9f%e6%83%b3#post-156 Sat, 10 Jul 2010 23:58:28 +0000 Todd 156@http://bbs.zhenghui.org/ 认识到系统的多维度与多粒度就不会陷入“盲人摸象”了。不会因为自己的视图而否定别人的视图，对未知的视图保持一份好奇和敬畏。 hui on "UML感想" http://bbs.zhenghui.org/topic/uml%e6%84%9f%e6%83%b3#post-155 Fri, 09 Jul 2010 19:53:16 +0000 hui 155@http://bbs.zhenghui.org/ 你的说法基本上是正确的，不过需要补充的是：这种视图不仅与抽象的角度有关，也与抽象的粒度或层次有关（比如package diagram的粒度比class diagram的更粗）。 Todd on "UML感想" http://bbs.zhenghui.org/topic/uml%e6%84%9f%e6%83%b3#post-154 Fri, 09 Jul 2010 18:05:45 +0000 Todd 154@http://bbs.zhenghui.org/ 如果把系统视为一个多维对象，那么UML的用例图、类图、序列图、状态图等是在不同维度上对该对象建立的视图。抽象的角度不同，抽象的结果就不同，根据不同的需要选择不同的抽象角度。不知道这样理解UML是否正确？ hui on "范畴论讲什么？" http://bbs.zhenghui.org/topic/%e8%8c%83%e7%95%b4%e8%ae%ba%e8%ae%b2%e4%bb%80%e4%b9%88%ef%bc%9f#post-134 Wed, 16 Jun 2010 17:28:15 +0000 hui 134@http://bbs.zhenghui.org/ 范畴理论是数学中抽象代数（abstract algebra）的一个分支，主要是以最抽象的方式研究数学结构以及它们之间的关系。每个范畴（category）包括一组对象（object），一组态射（morphism），以及态射之间的合成。对应于程序中的类型系统，这组对象可以看成某个数据类型所涵盖的所有对象，而态射则可以看成函数，态射合成对应于函数合成。在函数式语言Haskell中，这种对应更加清晰，而且Haskell中的functor和monad都直接来源于范畴理论中对应的概念。 更详细的可以参考： <a href="http://en.wikipedia.org/wiki/Category_theory" rel="nofollow">http://en.wikipedia.org/wiki/Category_theory</a> <a href="http://en.wikibooks.org/wiki/Haskell/Category_theory" rel="nofollow">http://en.wikibooks.org/wiki/Haskell/Category_theory</a> 从这里也看出，高级的数学知识对从更抽象和更高层的角度来理解编程是有意义的。但不是所有的人都习惯数学的思维方式，所以对一般程序员我并不推荐深入地学习，这种素养的培养比编程要困难得多。 Todd on "范畴论讲什么？" http://bbs.zhenghui.org/topic/%e8%8c%83%e7%95%b4%e8%ae%ba%e8%ae%b2%e4%bb%80%e4%b9%88%ef%bc%9f#post-133 Wed, 16 Jun 2010 10:05:35 +0000 Todd 133@http://bbs.zhenghui.org/ 记得郑老师曾经讲过范畴论(category theory)和程序类型系统是相通的，但是后者要简单得多。我想了解范畴论是讲什么的，尤其是还涉及了哪些方面是一般程序类型系统没有的？ Jee on "菜鸟读《冒号课堂》后的感触，望郑晖老师解惑" http://bbs.zhenghui.org/topic/%e8%8f%9c%e9%b8%9f%e8%af%bb%e3%80%8a%e5%86%92%e5%8f%b7%e8%af%be%e5%a0%82%e3%80%8b%e5%90%8e%e7%9a%84%e6%84%9f%e8%a7%a6%ef%bc%8c%e6%9c%9b%e9%83%91%e6%99%96%e8%80%81%e5%b8%88%e8%a7%a3%e6%83%91#post-118 Thu, 03 Jun 2010 10:07:40 +0000 Jee 118@http://bbs.zhenghui.org/ 非常感谢郑晖老师在百忙之中给予我如此详细的解答，作为你的读者我感到十分荣幸。 其实我提到数学的重要性就在于我能体会到数学抽象给人类思维带来的好处，单纯的为了计算机软件编程，或者为了某一个生活点，我想对个体发展的局限性是十分明显的，我从不抵触任何对将来的发展和生活有帮助的事物与知识，拜读《冒号课堂》并非仅仅是为了学会如何去编程，因为说到底23设计模式其实都是一个模式，就像是一个一个公式一样，然而公式的背后蕴藏的东西才是万事之根之源，我在网上读样章的时候就没有那他当本具体的工具书来读，显然我是对的，那样所取必定很少，且终将无法收获书中的精髓所在。在不算厚重的书本中读到的内容可能会对我以后对待技术、对待编程方式、对待设计思维都将有着比较大的影响。 我想单纯的用感谢来表达对郑晖老师的感激没有丝毫的意义，所以将以上的感触作为传道授业解惑的师者一个回馈，希望没能辜负郑晖老师解惑之言。 hui on "菜鸟读《冒号课堂》后的感触，望郑晖老师解惑" http://bbs.zhenghui.org/topic/%e8%8f%9c%e9%b8%9f%e8%af%bb%e3%80%8a%e5%86%92%e5%8f%b7%e8%af%be%e5%a0%82%e3%80%8b%e5%90%8e%e7%9a%84%e6%84%9f%e8%a7%a6%ef%bc%8c%e6%9c%9b%e9%83%91%e6%99%96%e8%80%81%e5%b8%88%e8%a7%a3%e6%83%91#post-117 Wed, 02 Jun 2010 19:20:24 +0000 hui 117@http://bbs.zhenghui.org/ 再说说专业方面的问题。你提到愿意重新自学大学课程，虽精神可嘉，但未必可取。从软件（或建筑）设计的观点来看，这是bottom-up法。作为学生，最好采用这种方法，但你已经参加工作了，所以我建议你更多地采用top-down法。这当然不是轻视基础知识，而是认为获取知识最高效的方法莫过于按需（on demand）学习。在实际工作中意识到某个知识点的重要性，从而有针对性地弥补短板，这样学习起来不仅更有效率，也更有兴味。需要强调的是，绝不能只是“头痛医头”，而要“拔萝卜带出泥”。只有寻根究底、以点带面，才能快速有效地建立起自己的知识结构体系。对于软件开发这类实践性很强的专业来说，该法尤其奏效。 话又说回来，这种项目驱动式的学习方法也是有一定局限的。毕竟大多项目涉及的深度和广度通常都很有限，单纯凭此建立起来的知识体系不可能非常完善。这就需要平时有计划地阅读一些经典著作以加强深度，并定期浏览一些高质量的技术网站以加强广度。 以上谈的都是一些较为宏观的建议，我想你需要的是更加具体的建议。《冒号课堂》上已经阐述了不少关于编程语言、编程范式、设计原则方面的观点，此处不复赘言。我想特别强调一点——把握抽象（abstraction）。事实上，无论是在书中还是本论坛中，我都不厌其烦地再三提到抽象的重要性，今后有时间还会深入地挖掘这一主题。对编程的语言、范式、设计、实现体会得越深，对抽象体会得也越深。借用Hakell的设计者之一Paul Hudak的一句略带夸张的话（overstatement）：“abstraction, abstraction, abstraction” are the three most important things in programming。一定会有人会问：难道编程语言就不重要了吗？设计模式就不重要了吗？算法设计就不重要了吗？那是他们尚未真正理解何为抽象——抽象不仅渗透在编程范式之中，也渗透在编程语言之中；不仅反映在设计原则之中，也反映在设计模式之中；不仅体现在架构设计之中，也体现在算法设计之中。 说来也怪，明明是想提“具体”建议的，偏偏又扯出了“抽象”，大概不是你想要的答案吧？既然你是计算机专业毕业的，又有一定的工作经验，其实也不需要太过具体的建议。你的苦恼是找不到努力的方向，而这个方向恐怕还是得靠自己去寻找。建议试试两种方法：研读一本有趣的名著或开发一个有趣的应用。只要深入其中，相信绝不会再为找不到方向而发愁，说不定倒会为方向太多而发愁呢。 最后，如果平时能有意识地积累一些计算机以外的领域知识（domain knowledge），比如金融、电信、教育、企业管理等等，对提高在IT业的个人核心竞争力也是大有裨益的。当然，前提是你有兴趣或有条件获得这些知识。 一家之言，希望能对你有所帮助。 hui on "菜鸟读《冒号课堂》后的感触，望郑晖老师解惑" http://bbs.zhenghui.org/topic/%e8%8f%9c%e9%b8%9f%e8%af%bb%e3%80%8a%e5%86%92%e5%8f%b7%e8%af%be%e5%a0%82%e3%80%8b%e5%90%8e%e7%9a%84%e6%84%9f%e8%a7%a6%ef%bc%8c%e6%9c%9b%e9%83%91%e6%99%96%e8%80%81%e5%b8%88%e8%a7%a3%e6%83%91#post-116 Wed, 02 Jun 2010 04:04:25 +0000 hui 116@http://bbs.zhenghui.org/ 你提到的问题十分典型，我非常理解你的心情，同时也非常乐意分享一些个人的看法。 虽然你在言语之中流露出不少负面的情绪，但我看到的却是正面的希望。首先，你对软件技术很感兴趣，而兴趣是学习和工作的最大动力。一般说来，我也没兴趣回答那些对编程不感兴趣者的有关编程的问题。一方面，我会劝他们改行，否则彼此都痛苦；另一方面，我建议的方法通常也不适合他们。其次，你很清楚地意识到自己在哪些方面不足，这是一切进步的基础。许多程序员意识不到自己的无知，甚至自以为足够有知，那又如何能进步呢？最后，你不指望任何捷径，愿意通过踏踏实实的学习来弥补不足。在浮躁之风盛行的当下，这点也是难能可贵的。 关于数学基础，窃以为并非什么太大的问题。几乎每个得知我数学背景的人都会对我说：哦，学数学的人来学计算机自然容易啦。事实上，这种观点虽然极为普遍，但也极为肤浅。本人从事数学14年（从本科算起）、从事计算机12年（与前者有部分重合），在这一点上还是比较有发言权的。事先说明，以下提到的数学不包括高中数学。其实大多数从事软件开发的人员用不到太多的数学知识，他们只需要正常的逻辑思维能力和抽象思维能力。整天拿数学说事，要么是无知，要么是找借口，要么是装高深。当然，我不否认一些高级算法、计算机理论以及人工智能等领域可能涉及到高深的数学知识（其实也只是图论、组合数学、数论、概率论、计算几何、抽象代数、数学逻辑等中的一小部分），但那毕竟只是少数。我也不否认自己的数学背景有助于对编程的理解，但投入产出比太低，不值得作为经验来推广。不过若想成为一位计算机科学家，那就另作别论了——这时数学懂得再多也会嫌少的。 倒是英语我希望你更重视些。我在《冒号课堂》（http://blog.zhenghui.org/2009/09/10/colon-class-3_3/）中专门提过阅读原著的必要性，而且你也意识到译著的质量问题。建议不必特地去学习英语（你本来就会了，不是吗？），只要坚持读经典原著即可。其实，计算机方面的英文算是很容易的了，关键是克服自己的惯性和惰性。开始可能不习惯，看多了就习惯了。在此提醒一点，在阅读时请有意识地培养自己对英语的语感，就像编程时要有意识地培养自己对编程语言的语感一样。 总之，对于程序员来说，数学没有人们认为的那么重要，英语没有人们认为的那么不重要。 （未完待续） Jee on "菜鸟读《冒号课堂》后的感触，望郑晖老师解惑" http://bbs.zhenghui.org/topic/%e8%8f%9c%e9%b8%9f%e8%af%bb%e3%80%8a%e5%86%92%e5%8f%b7%e8%af%be%e5%a0%82%e3%80%8b%e5%90%8e%e7%9a%84%e6%84%9f%e8%a7%a6%ef%bc%8c%e6%9c%9b%e9%83%91%e6%99%96%e8%80%81%e5%b8%88%e8%a7%a3%e6%83%91#post-115 Tue, 01 Jun 2010 13:14:33 +0000 Jee 115@http://bbs.zhenghui.org/ 之前在Top language里的一位网友像我推荐您的《冒号课堂》，书中eric向您建议开设社区，我猜测可能会有，就找到您的博客发现此地，很幸运您是一个如此有责任心的作者。 我是一名没有什么理论基础的不合格的计算机专业毕业生，毕业后却对软件方面技术非常感兴趣，可能与个性有关。于是在这近2年的找工作和工作过程中看了一些书，也和一些过来人聊过，总体来说让我对软件编程有了一点认识。在阅读您的冒号课堂之前，我曾一度认为我所差的是经验和一些诸如高级算法之类的进阶技术，可现在，一个用了一个多月时间的夜晚阅读《冒号课堂》之后的我发现我所差的不仅仅是那些，而是最基础最根本的对计算机本身的认识，对数学的认识，对软件工程的认识。 我不想能有速成一说，只想能够现在正视自己，脚踏实地的一点一点的学习和进步，哪怕让我自学4年大学课程也未尝不可，只是有些时候有点找不到一个开始。我数学不好，作为一名程序员我想这是个令人沮丧的事实，我英语也不好，当看到蹩脚的一些翻译著作后痛苦不已。我想尝试着去改变这些，但是却不知该如何去做，您知道，作为一名已经进入社会的成年人，我需要承受一些生存的压力和一些生活的负担，我希望能更好的利用每天那抽出来的时间，所以望郑晖老师能给我指出一条明道。 我一直没有说我从事的语言和方向，因为我知道这并不是核心，也不是想从您这得到如何学习XX语言等。万分打扰，还望见谅。 Todd on "抽象是什么？" http://bbs.zhenghui.org/topic/%e6%8a%bd%e8%b1%a1%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-112 Wed, 19 May 2010 16:37:20 +0000 Todd 112@http://bbs.zhenghui.org/ 最近在看系统论方面的书，系统论中有一个关于变化和不变的论述：只有通过变化才能理解不变。这让我突然对“测试”有所感悟，测试就是通过变化寻找不变的过程。这里的“测试”还包括生活中的例子，比如要了解一个人的品质，我们需要通过很多事例，这些事例是变化的，但通过这些变化的事例我们能体会到这个人品质中的某些不变特征。 上面的感悟不一定对，随感而发。 hui on "为什么是这4个原则？" http://bbs.zhenghui.org/topic/%e4%b8%ba%e4%bb%80%e4%b9%88%e6%98%af%e8%bf%994%e4%b8%aa%e5%8e%9f%e5%88%99%ef%bc%9f#post-94 Wed, 24 Mar 2010 16:18:17 +0000 hui 94@http://bbs.zhenghui.org/ 设计原则有很多，但归根结底是抽象原则。书中提到的抽象可能比SCIP中的abstraction更广义：模块化的本质也是抽象——它无非是如何划分抽象边界的问题。本书中将设计原则归为间接、依赖、内聚和保变等四类，主要是考虑到它们具有典型代表性，而且以之为中心组织内容比较方便。 Todd on "为什么是这4个原则？" http://bbs.zhenghui.org/topic/%e4%b8%ba%e4%bb%80%e4%b9%88%e6%98%af%e8%bf%994%e4%b8%aa%e5%8e%9f%e5%88%99%ef%bc%9f#post-93 Wed, 24 Mar 2010 14:57:58 +0000 Todd 93@http://bbs.zhenghui.org/ 设计原则有很多，比如熟悉的DRY，SOLID等原则。本书选择了间接，依赖，内聚和保变4个设计原则作为大的分类。这样选择的用意是什么呢？ SCIP先讲了抽象（等同于间接），然后讲模块化（等同于内聚），可能SCIP的作者也认为抽象和内聚应该是一级原则。下面是SCIP的一段话： The preceding chapters introduced the basic elements from which programs are made. We saw how primitive procedures and primitive data are combined to construct compound entities, and we learned that abstraction is vital in helping us to cope with the complexity of large systems. But these tools are not sufficient for designing programs. Effective program synthesis also requires organizational principles that can guide us in formulating the overall design of a program. In particular, we need strategies to help us structure large systems so that they will be modular, that is, so that they can be divided <code></code>naturally'' into coherent parts that can be separately developed and maintained. Todd on "数据是什么？" http://bbs.zhenghui.org/topic/%e6%95%b0%e6%8d%ae%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-92 Mon, 22 Mar 2010 11:59:45 +0000 Todd 92@http://bbs.zhenghui.org/ 数据抽象把数据分为：外部接口和内部表示(representation)两部分。我觉得函数式数据的内部表示非常神奇，就好象是人的基因一样。 hui on "数据是什么？" http://bbs.zhenghui.org/topic/%e6%95%b0%e6%8d%ae%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-91 Sat, 20 Mar 2010 22:49:42 +0000 hui 91@http://bbs.zhenghui.org/ 不错，λ-calculus的威力（图灵完备）由此可见一斑。 Todd on "数据是什么？" http://bbs.zhenghui.org/topic/%e6%95%b0%e6%8d%ae%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-90 Sat, 20 Mar 2010 18:40:02 +0000 Todd 90@http://bbs.zhenghui.org/ 以前看过的Church计数，当时完全不理解是怎么回事，只觉得很有趣。现在认识到数据和操作是不可分割的，才有了更深的理解。数学真是神奇，把日常生活中的1，2，3都能发现出这么深刻的道理！ <a href="http://en.wikipedia.org/wiki/Church_numeral" rel="nofollow">http://en.wikipedia.org/wiki/Church_numeral</a> hui on "数据是什么？" http://bbs.zhenghui.org/topic/%e6%95%b0%e6%8d%ae%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-89 Fri, 19 Mar 2010 12:42:00 +0000 hui 89@http://bbs.zhenghui.org/ 没错，所谓队列，就是有FIFO机制的类型。这是一个整体概念，应当是一个抽象的type，而不是具体的struct。C虽然在语法上不完备地支持ADT（没有封装机制），但还是能从概念上支持的。 Todd on "数据是什么？" http://bbs.zhenghui.org/topic/%e6%95%b0%e6%8d%ae%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-88 Fri, 19 Mar 2010 12:24:15 +0000 Todd 88@http://bbs.zhenghui.org/ 谢谢！可不可以这样理解《冒号课堂》中的C语言实现队列的例子：虽然还是C语言的一组函数，但它的目的已经不是过程抽象，而是数据抽象。OOP让数据抽象变得更自然。 hui on "数据是什么？" http://bbs.zhenghui.org/topic/%e6%95%b0%e6%8d%ae%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-87 Fri, 19 Mar 2010 12:02:54 +0000 hui 87@http://bbs.zhenghui.org/ >>OOP的数据抽象正是以数据为中心组织操作 这个说法稍微有点问题。既然上面提到的“数据”是用“操作”来定义的，那么“以数据来组织操作”便有循环定义之嫌了。《冒号课堂》中的提法是：OOP是“以数据为中心组织逻辑”(P39)。 这么说可能更清楚些：在OOP中，定义数据抽象是类的设计者的任务，选择数据结构(data structure)并以之为中心实现各接口是类的实现者的任务。（在实际编程中，这二者的角色可能一人承担） hui on "数据是什么？" http://bbs.zhenghui.org/topic/%e6%95%b0%e6%8d%ae%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-86 Fri, 19 Mar 2010 11:29:12 +0000 hui 86@http://bbs.zhenghui.org/ >>数据本身只是一个符号，它的特征是由其相关的一系列操作（包括构造和使用两类）所体现的 这种理解是正确的。之所以说数据是抽象的，是因为我们不关心其内部的具体结构表示（representation），只关心它是如何被创建、如何被使用的。也就是说，数据应当被当作一个黑箱来使用，任何超过其定义的使用方式都是侵犯其隐私、破坏其抽象的行为。 不过，上述“符号”二字或许改为“对象”（广义的对象，并非OOP中狭义的对象）更贴切些，因为前者容易让人把数据与指代它的变量混为一谈。事实上，在你参考的文章中也是使用“data object”的字眼。 如果以这种方式来理解数据，那么就很容易理解“函数也是数据”的思想了。在SICP中讲述的Scheme语言正体现了这种函数式风格。 在此基础上，（抽象）数据类型的概念也非常自然了。ADT关心的是通过接口定义在一类数据上的行为，而不是它们的内部数据结构。 Todd on "数据是什么？" http://bbs.zhenghui.org/topic/%e6%95%b0%e6%8d%ae%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-85 Fri, 19 Mar 2010 10:22:32 +0000 Todd 85@http://bbs.zhenghui.org/ 今天看了SCIP的数据抽象一节，然后结合之前《冒号课堂》的内容，我感觉对数据的认识又深入了一些。 我现在对数据的认识是：数据在程序中是一个符号和该符号上的操作规则。比如：定义了一个符号pair，若pair = make_pair(x, y)则left(pair) == x, right(pair) == y。pair本身只是一个符号，它的特征是由其相关的一系列操作（包括构造和使用两类）所体现的。OOP的数据抽象正是以数据为中心组织操作。不知道理解对不对？ 参考文章： <a href="http://mitpress.mit.edu/sicp/full-text/sicp/book/node30.html" rel="nofollow">http://mitpress.mit.edu/sicp/full-text/sicp/book/node30.html</a> hui on "抽象是什么？" http://bbs.zhenghui.org/topic/%e6%8a%bd%e8%b1%a1%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-72 Tue, 02 Mar 2010 20:15:29 +0000 hui 72@http://bbs.zhenghui.org/ 你的理解非常正确。请注意以上我提到的那句话：“数据抽象不是在类的实现过程中发生的，而是在类的设计阶段发生的”，特意分别在实现和设计前面加了修饰词“类的”。 这也再次印证书中的一句话：“与其区分设计与实现，不如把握抽象的级别” rstevens on "抽象是什么？" http://bbs.zhenghui.org/topic/%e6%8a%bd%e8%b1%a1%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-71 Tue, 02 Mar 2010 19:41:21 +0000 rstevens 71@http://bbs.zhenghui.org/ 谢谢及时回复，我之所以理解混论，主要是纠结于书中所说的“数据抽象发生在实现阶段”。 这样理解或许更为准确： 1、从分析、设计、实现的层次看，数据抽象发生在实现阶段，（书中所说，数据冲向是实现阶段的五种抽象之一）。具体来说，就是在实现一个类的过程中。 2、在实现一个类的过程中，又自然的分为“设计”与“实现”两个步骤，或者两个过程；因为在实现之前，必然有一个设计的思考过程。数据抽象就发生在这个阶段的“设计”过程中。 hui on "抽象是什么？" http://bbs.zhenghui.org/topic/%e6%8a%bd%e8%b1%a1%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-70 Tue, 02 Mar 2010 19:39:08 +0000 hui 70@http://bbs.zhenghui.org/ >>1、如果说先有了“接口规范”，并且“数据抽象”是在定义出类的对外接口（API）就完成了，那么实际上在定义完“接口规范”的时候，就已经完成了“数据抽象” 2、更接近实际的情况时，并没有“接口规范”，但是需要实现一个类，或者已经实现了一个类；在优化代码的过程中，通过“数据抽象”，提炼出类的对外行为规范，设计出接口（API），并将内部实现封装起来；整个过程，称为“数据抽象”。 没错，你提到的第一点是比较理想的过程，第二点是比较实际的过程。但值得指出的是，后者是一个从已有的实现中重新设计的过程，即refactoring。需要refactoring意味着原来设计不尽合理，其原因主要有两种：一是程序员对数据抽象的认识不够或重视不够，在没有设计好API之前就匆匆写实现代码；二是该类的上层类/客户类因自身设计原因或外部需求变化原因发生改变，从而导致类的接口改变。 在类的hierarchy设计中，类似的情况也时有发生。有时是先有超类，后有子类；有时是从一些类中提炼出超类。这不奇怪，没有人能从一开始就设计出一个完美的系统，因此会交替在高层抽象（接口、超类）和低层抽象（实现、子类）之间往返（top-down/bottom-up）。 hui on "抽象是什么？" http://bbs.zhenghui.org/topic/%e6%8a%bd%e8%b1%a1%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-69 Tue, 02 Mar 2010 19:16:14 +0000 hui 69@http://bbs.zhenghui.org/ >>我理解，抽象是一种思维的“过程”，包括思考发生的场合（层次）、思考的方式（如何筛选） 1。根据上下文，抽象可以指思维的“过程”，也可以指思维的“结果”。 2。思考发生的场合与层次有关，但不完全等同。抽象的层次越高，忽略的（实现）细节越多。 >>1、数据抽象发生在实现阶段，通常是在如何实现一个类的过程中发生的。 数据抽象不是在类的实现过程中发生的，而是在类的设计阶段发生的。事实上，数据抽象的意义正是在于：给定一个API，可以有不同的实现方式。在现实中，不少程序员在API没有规范好之前就开始动手写实现代码，但这不是一种值得推荐的做法。当然，这里也有个抽象层次问题——如果一个类比较底层，仅仅是为另一个高层类提供内部服务，这个要求可以稍微放宽。 >>2、在进行数据抽象之前，已进行了“规范抽象”，提炼出了“接口规范” 这么说可能更好：数据抽象是借助（或依赖）了“规范抽象”，不必把它们硬性分开。 >>3、数据抽象是将“接口规范”映射到具体实现（通常指一个类）的过程 从设计者的角度看，数据抽象是形成“接口规范”的过程；从客户的角度看，数据抽象是忽略具体实现的保证。 >>4、抽象的方式是，按照“接口规范”定义出类的对外接口（API）；到此为止，“数据抽象”已经结束 这种说法是对的，但不是与你前面提出的1和3矛盾吗？事实上，你在后来的两个帖子中也意识到这个矛盾了:) >>5、数据抽象完成后，再考虑类的具体实现；围绕的是数据的组织方式、算法实现进行的；这些具体实现通过封装机制隐藏起来。 正确。