冒号论坛 » Tag: abstraction

冒号论坛 » Tag: abstraction - Recent Posts http://bbs.zhenghui.org/tags/abstraction 冒号论坛 » Tag: abstraction - Recent Posts en-US Wed, 08 Feb 2012 23:31:15 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://bbs.zhenghui.org/search.php Lumj on "抽象机制" http://bbs.zhenghui.org/topic/%e6%8a%bd%e8%b1%a1%e6%9c%ba%e5%88%b6#post-325 Thu, 09 Jun 2011 19:50:35 +0000 Lumj 325@http://bbs.zhenghui.org/ 我看了您推荐的读物,不得不说我仍然认为将迭代抽象与其它4者相提并论欠妥.. 就好比..我们不会给书增加一个新的章节,叫'IO抽象',然后给出文件流抽象之类的例子,并配以"IO抽象使得程序员不必关心诸如缓冲之类的事,只需与逻辑上的Stream打交道"之类的陈述 folger on "抽象机制" http://bbs.zhenghui.org/topic/%e6%8a%bd%e8%b1%a1%e6%9c%ba%e5%88%b6#post-324 Mon, 06 Jun 2011 17:43:46 +0000 folger 324@http://bbs.zhenghui.org/ 同感,迭代更像是其他抽象的一个应用,先看看上面的资料... Lumj on "抽象机制" http://bbs.zhenghui.org/topic/%e6%8a%bd%e8%b1%a1%e6%9c%ba%e5%88%b6#post-307 Sat, 26 Mar 2011 23:34:55 +0000 Lumj 307@http://bbs.zhenghui.org/ 好的,最近一次21世纪计算大会,她是演讲人之一,我当时不识泰山,只觉得她的话题很有感(她谈的就是abstraction),后来才知道就是她的Liskov principle hui on "抽象机制" http://bbs.zhenghui.org/topic/%e6%8a%bd%e8%b1%a1%e6%9c%ba%e5%88%b6#post-305 Sat, 26 Mar 2011 23:08:35 +0000 hui 305@http://bbs.zhenghui.org/ Lumj: 建议你看看图灵奖获得者Barbara Liskov（就是那位提出Liskov原则的女士）的书《Program Development in Java: Abstraction, Specification, and Object-Oriented Design》，该书第六章专门谈到迭代抽象。无论java是否为你的熟悉或喜欢的语言，这本书都值得看。 另外，《冒号课堂》每节后面都有参考资料，可进行延伸阅读。 Lumj on "抽象机制" http://bbs.zhenghui.org/topic/%e6%8a%bd%e8%b1%a1%e6%9c%ba%e5%88%b6#post-303 Sat, 26 Mar 2011 11:10:39 +0000 Lumj 303@http://bbs.zhenghui.org/ 冒号老师,其实我读到这里的时候,感觉'迭代抽象'出现在其它那4者中间不太合适,因为那4个抽象是..怎么说呢..'编程模型'层面的,而'迭代'却是程序功能层面的,我感觉不应该放在一起讨论 Lumj on "冒号老师,如果有人这样问你,你会怎样回答?" http://bbs.zhenghui.org/topic/%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%a6%82%e6%9e%9c%e6%9c%89%e4%ba%ba%e8%bf%99%e6%a0%b7%e9%97%ae%e4%bd%a0%e4%bd%a0%e4%bc%9a%e6%80%8e%e6%a0%b7%e5%9b%9e%e7%ad%94#post-301 Mon, 07 Mar 2011 18:15:18 +0000 Lumj 301@http://bbs.zhenghui.org/ Ah..虽然说看了冒号老师你写的这些我觉得还是没有挠到最痒处的感觉(总觉得离我最想要得到的那个东西还差那么一点),但这个问题我仔细思考过,所以你的回答中的一些理论化的词汇的使用我就特别在意,增加了对这些词汇的理解 也许我将来可以使用自己的词汇把我的想法表达出来:) PS: 最近两天突然对你的书中对值类型和引用类型的讨论有了悟透的感觉(书早就还掉了),尤其是那句"逻辑上的值语义不一定通过语言中的值类型来实现(或者说表达)","不可变的引用类型试图表达了值语义",还有"值类型是不可变的,值类型变量的赋值是新旧更替",从而又联想到这个这里的一个帖子提到的"一切皆流"观点,有醍醐灌顶的感觉,哈哈!!!!一直到这里我才认为自己对"人不能两次踏入同一条河流"这句话有了些真正的(虽然也许不是全部的)理解 hui on "冒号老师,如果有人这样问你,你会怎样回答?" http://bbs.zhenghui.org/topic/%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%a6%82%e6%9e%9c%e6%9c%89%e4%ba%ba%e8%bf%99%e6%a0%b7%e9%97%ae%e4%bd%a0%e4%bd%a0%e4%bc%9a%e6%80%8e%e6%a0%b7%e5%9b%9e%e7%ad%94#post-299 Mon, 07 Mar 2011 12:43:47 +0000 hui 299@http://bbs.zhenghui.org/ 这是个很好的问题，而且是个很实际的问题。你的意思我完全明白，事实上你的解释已经很接近问题的本质，只是没能用更理论化的语言表述而已。 抛开性能因素，用array的做法之所以不合适，原因很简单，即数据没有结构化，类型没有语义化。说到底，是数组类型过于底层，没有抽象的封装。即使不是OOP的fan，我们也可简单地通过夸张array的做法来看出其不合理性：按这种思路，array不仅可替代NameValuePair这样的二元组，还可替代三元组、四元组、N元组。如果这样，C中的struct、union，C++、Java、C#等中的class等的作用也大打折扣了。 编程语言一代代进化，一个重要标志就是语言的抽象性更强，语义的表达力更丰富，用array来实现NameValuePair是一种开倒车的做法。当然，如果为了性能优化，或临时、局部地应用，这也不是完全不可取。为了性能原因，程序员（尤其是C程序员）甚至会把一个整数的每一个bit都赋予特殊的意义，换言之，把整数当作bit array来使用。只是单从设计的角度看，这类技巧的缺陷是很明显的。因为一个数组中元素所代表的意义没有显式的表达，只是隐藏在非常原始的数组下标上，降低了代码的可读性和可维护性。比如，用户可能写错下标，或者不慎造成下标越界。此外，这种做法对需求变化的适应性很差，如果以后需要为NameValuePair array增加新的属性或行为，会极大地影响客户代码。如果采用NameValuePair class，则会大大减少代码修改量。还有一个很现实的问题：前者修改的范围不仅大得多，而且也难找得多。因为array太普通，不易定位。而如果采用NameValue的命名结构，在代码中搜索起来也快得多。 此外还有另一个语义问题：数组的一般用法是各元素是同类型的，这种类型不仅是语法类型，而且是语义类型。NameValuePair中name一般是string类型，value则未必。即使也是string类型，它们在语义上也是不等同的。如果一定要用通用的底层来表示，那么tuple也比array更合适一些。比如Python便支持tuple，与array最大不同的是，tuple可以是异构的，并且是immutable（不可变的）。当然，如果语言（比如javascript、ruby、php、python等）直接支持key-value类型，自然最好不过，只是我们讨论的前提应该是这种类型不被语言原生支持。 Lumj on "冒号老师,如果有人这样问你,你会怎样回答?" http://bbs.zhenghui.org/topic/%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%a6%82%e6%9e%9c%e6%9c%89%e4%ba%ba%e8%bf%99%e6%a0%b7%e9%97%ae%e4%bd%a0%e4%bd%a0%e4%bc%9a%e6%80%8e%e6%a0%b7%e5%9b%9e%e7%ad%94#post-298 Mon, 07 Mar 2011 09:35:58 +0000 Lumj 298@http://bbs.zhenghui.org/ 我杜撰了一个错误的设计,并想以它为例来告诉别人某类设计是错误的,但是我发现我可用以表达的词汇不够,由此陷入一种很奇怪的境地,所以突发奇想想看看冒号老师会怎样回答 在需要一个NameValuePair的地方,某人说:"唉,再去写个NameValuePair class太烦了,不就是两个变量放一起么",然后在需要传递NameValuePair的地方都以Array[2]来代替,每次取出array[0]当作name,Array[1]当作value,如此工作 我的想法是,这样做的确能工作,但是语义上是错误的,如果感性地表达一下我的感觉,像是这样: Array里的东西是'数出来的',并且各个元素没有相互之间的独特性(这个形容相当拙劣,我找不到好的词语),而NameValuePair里的东西是'枚举出来的' 就好像,对一个班级里的学生们,老师的看待方式会是这样:一个班长,一个副班长,一个学习委员,一个..等等,最后,剩下的是一个学生数组,如果问起班长之类的,老师会说出名字和其它他的各种表现,而问起那个学生数组里的人,也许会想一想才分辨出他的各种信息(哎?!我写到这才发现,这个'想一想'好像暗合了Array的性能劣势),因为那个学生数组里的学生是被批量看待的 不知冒号老师是否理解了我的想法,是否有好的词汇和语句可以直截了当地说明这个设计的错误 PS:不考虑性能之类的问题,就考虑语义问题 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都直接来源于范畴理论中对应的概念。 更详细的可以参考： http://en.wikipedia.org/wiki/Category_theory http://en.wikibooks.org/wiki/Haskell/Category_theory 从这里也看出，高级的数学知识对从更抽象和更高层的角度来理解编程是有意义的。但不是所有的人都习惯数学的思维方式，所以对一般程序员我并不推荐深入地学习，这种素养的培养比编程要困难得多。 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都能发现出这么深刻的道理！ http://en.wikipedia.org/wiki/Church_numeral 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（没有封装机制），但还是能从概念上支持的。