http://bbs.zhenghui.org/ 冒号论坛 » Recent Posts en-US Fri, 30 Jul 2010 03:28:01 +0000 http://bbpress.org/?v=1.0.2 q http://bbs.zhenghui.org/search.php http://bbs.zhenghui.org/topic/object%e8%8c%83%e5%bc%8f%e4%b8%8estream%e8%8c%83%e5%bc%8f#post-165 Thu, 29 Jul 2010 22:32:08 +0000 hui 165@http://bbs.zhenghui.org/ <p>C#、ruby、python等语言确可以利用yield来产生无穷序列，术语称协程（coroutine）。在合适的场合使用这一特性可以让代码更加简明、清晰。另外，这也可看作是函数式所倡导的惰性求值（lazy evaluation）的一种特殊情形。 </p> http://bbs.zhenghui.org/topic/object%e8%8c%83%e5%bc%8f%e4%b8%8estream%e8%8c%83%e5%bc%8f#post-164 Thu, 29 Jul 2010 21:27:44 +0000 Todd 164@http://bbs.zhenghui.org/ <p>今天我用C#的yield实现了一个无限流的Stack。Stack的输入是(operation, data)的流，输出是(data)流:<br /> <pre><code>class Stack{ public static IEnumerable&lt;int&gt; Transform(IEnumerable&lt;Command&gt; aSourceStream){ LinkedList&lt;int&gt; list = new LinkedList&lt;int&gt;(); foreach(Command command in aSourceStream){ if(OperationType.PUSH== command.Operation){ list.AddLast(command.Data); } else if (OperationType.POP == command.Operation){ int data = list.Last.Value; list.RemoveLast(); yield return data; } } } }</code></pre> http://bbs.zhenghui.org/topic/object%e8%8c%83%e5%bc%8f%e4%b8%8estream%e8%8c%83%e5%bc%8f#post-163 Wed, 28 Jul 2010 19:44:02 +0000 Todd 163@http://bbs.zhenghui.org/ <p>虽然stream processing不一定能作为一种范式，看了SICP的介绍我觉得它还是很具有代表性的一种模型。 </p> http://bbs.zhenghui.org/topic/object%e8%8c%83%e5%bc%8f%e4%b8%8estream%e8%8c%83%e5%bc%8f#post-162 Wed, 28 Jul 2010 10:59:02 +0000 hui 162@http://bbs.zhenghui.org/ <p>object本身并不是编程范式，而object-oriented才是。类似地，stream本身不宜作为独立的编程范式（事实上在SCIP中，它如同object一样被当作一种data structure），相应的stream processing更适合作为一种计算模型（computational model），既可用于函数范式，也可用于并发范式。</p> <p>另请参见http://en.wikipedia.org/wiki/Stream_processing。 </p> http://bbs.zhenghui.org/topic/object%e8%8c%83%e5%bc%8f%e4%b8%8estream%e8%8c%83%e5%bc%8f#post-161 Wed, 28 Jul 2010 10:06:54 +0000 Todd 161@http://bbs.zhenghui.org/ <p>SICP的第3章比较了object与stream两种范式，但很可惜《冒号课堂》里面没有把stream列为一个独立的范式进行讨论。</p> <p><a href="http://mitpress.mit.edu/sicp/full-text/sicp/book/node50.html" rel="nofollow">http://mitpress.mit.edu/sicp/full-text/sicp/book/node50.html</a> </p> http://bbs.zhenghui.org/topic/dbc%e5%92%8ctdd#post-160 Mon, 26 Jul 2010 11:49:37 +0000 Todd 160@http://bbs.zhenghui.org/ <p>对，的确有重叠之处。 </p> http://bbs.zhenghui.org/topic/dbc%e5%92%8ctdd#post-159 Sun, 25 Jul 2010 17:40:35 +0000 hui 159@http://bbs.zhenghui.org/ <p>二者既有互补之处，也有重叠之处。另外，好的DbC框架可以自动生成一些测试用例。 </p> http://bbs.zhenghui.org/topic/dbc%e5%92%8ctdd#post-158 Sun, 25 Jul 2010 11:48:18 +0000 Todd 158@http://bbs.zhenghui.org/ <p>昨天看了一个老外的视频讲座，他谈到：DbC适合用于表达无副作用的条件约束(constraint)；TDD适合用于表达类的外部行为(behavior)。二者是互补关系，可以结合使用。</p> <p><a href="http://www.infoq.com/presentations/TDD-in-a-DbC-World-Greg-Young" rel="nofollow">http://www.infoq.com/presentations/TDD-in-a-DbC-World-Greg-Young</a> </p> 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/ <p>说得很好，这是一个普适的结论，不仅适用于软件系统，也适用于一切认知对象。 </p> 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/ <p>认识到系统的多维度与多粒度就不会陷入“盲人摸象”了。不会因为自己的视图而否定别人的视图，对未知的视图保持一份好奇和敬畏。 </p> 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/ <p>你的说法基本上是正确的，不过需要补充的是：这种视图不仅与抽象的角度有关，也与抽象的粒度或层次有关（比如package diagram的粒度比class diagram的更粗）。 </p> 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/ <p>如果把系统视为一个多维对象，那么UML的用例图、类图、序列图、状态图等是在不同维度上对该对象建立的视图。抽象的角度不同，抽象的结果就不同，根据不同的需要选择不同的抽象角度。不知道这样理解UML是否正确？ </p> http://bbs.zhenghui.org/topic/%e5%a4%9a%e6%80%81%e7%9a%84%e6%9c%ac%e8%b4%a8%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-153 Tue, 06 Jul 2010 12:21:47 +0000 hui 153@http://bbs.zhenghui.org/ <p>你的理解是正确的。多态，准确地说是类型多态（type polymorphism），是指不同的数据类型（data type）符合统一的接口规范。也可以反过来说：一个接口（或类型）允许有不同的实现，但完全可以被接口的使用者忽略，从而达到抽象的效果。多态这一术语应当出自后一种角度。 </p> http://bbs.zhenghui.org/topic/%e5%a4%9a%e6%80%81%e7%9a%84%e6%9c%ac%e8%b4%a8%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9f#post-152 Tue, 06 Jul 2010 12:03:16 +0000 Todd 152@http://bbs.zhenghui.org/ <p>多数人以为多态就是基于继承的子类型多态，而书中提到了几种不同的多态。为什么这几种不同的形式都被称为多态呢？它们的共同点或者说多态的本质是什么？我思考的结果是：类型（Type）是语义要求，类（class，struct）等是语法机制，多态的本质是不同的类满足同一类型的要求，即同一语义不同语法。 </p> http://bbs.zhenghui.org/topic/%e6%80%80%e7%96%91%e8%ae%ba%e8%80%85%e7%9a%84%e6%80%80%e7%96%91#post-151 Fri, 02 Jul 2010 13:10:10 +0000 Todd 151@http://bbs.zhenghui.org/ <p>我举个例子，该不该买房？这个问题有两个子问题：1.房价是否继续上涨？2.如果买了100万的房子，贷款70万，每个月要还多少钱？</p> <p>第一个问题你有很多理由去怀疑它，因为它没有充分可靠的前提；但第二个问题你就不应该再去怀疑它，前提已经摆在那里了，算就行了。 </p> http://bbs.zhenghui.org/topic/%e6%80%80%e7%96%91%e8%ae%ba%e8%80%85%e7%9a%84%e6%80%80%e7%96%91#post-150 Fri, 02 Jul 2010 12:20:05 +0000 hui 150@http://bbs.zhenghui.org/ <p>你这个问题我本来是要在《论思维的柔性与刚性》中回答的，这里简单说一下我的观点。</p> <p>怀疑论本是合理的，对很多事情不轻易下定论是一种正确的态度。按照我的定义，这属于思维的柔性部分。没有怀疑精神，人类不可能自求进步。然而简单的怀疑不应当成为终点，相反应当是对真理进一步探索的起点。这种寻根究底的精神，便是思维的刚性部分。没有这种精神，当然会阻碍对真理（真相）的认识和思考。只有在怀疑的基础上进行深入的研究，才能获得一定程度的确信，认识由此获得了提升，而在新的层次上又会有新的怀疑，这个过程循环递进，思维也在柔性和刚性之间不断地转换。</p> <p>至于世界是否可以认识的，这是一个认识论中的基本问题。任何一个形而上学的问题都是没有真正答案的，自称给出答案的人不过是阐明了他的观点，却无法证明他的观点。援引我在<a href="http://blog.zhenghui.org/2010/04/19/hard-thinking-and-soft-thinking-1/">论思维的刚性与柔性（科学的迷信-上）</a> 中的一段话——<br /> 有一个假设是所有的科学都无法逃避的，即科学研究的对象是有规律的。（如果您觉得这本是天经地义的话，请复习以上休谟先生的发言）人们采纳该假设绝不是因为证明了客观规律的存在性，而是出于一种信念，或者一种无奈——倘若不信，我们还能做什么呢？</p> <p>虽然规律的存在性与可认识性并非等同的概念，但对于自信有智慧并且不满足于现状的人类来说，宁愿同时肯定它们，否则如何展现他们无与伦比的智慧呢？ </p> http://bbs.zhenghui.org/topic/%e6%80%80%e7%96%91%e8%ae%ba%e8%80%85%e7%9a%84%e6%80%80%e7%96%91#post-149 Fri, 02 Jul 2010 09:28:26 +0000 facingwaller 149@http://bbs.zhenghui.org/ <p>郑老师好：<br /> 我是一个 怀疑论者，对很多事情不置可否，认为 “有可能”是这样，也不排除不是的可能。<br /> 看似是”明哲保身“的调调，是否也阻碍了对真相的认识和思考？</p> <p>那么该如何对待呢？</p> <p>世界上可以认识的吗？</p> <p> -冒号课堂的读者。 </p> http://bbs.zhenghui.org/topic/ruby-on-rails%e6%9c%89%e4%bb%80%e4%b9%88%e7%89%b9%e8%89%b2%ef%bc%9f#post-148 Wed, 30 Jun 2010 19:50:26 +0000 hui 148@http://bbs.zhenghui.org/ <p>相比webwork，struts等Java web框架，RoR也是基于MVC的，但前者常常依靠大量繁琐的XML配置文件，而后者则遵循CoC原则，在一定程度上减轻了开发者的负担。更重要的是，Ruby作为一种既简洁又灵活的动态语言，比Java的开发效率更高，也更容易贯彻敏捷开发的理念。在敏捷成风的当下，更容易受到青睐。当然，Java中的各种web框架更加成熟，目前仍在大型企业应用中占据主导地位。 </p> http://bbs.zhenghui.org/topic/ruby-on-rails%e6%9c%89%e4%bb%80%e4%b9%88%e7%89%b9%e8%89%b2%ef%bc%9f#post-147 Wed, 30 Jun 2010 19:21:11 +0000 Todd 147@http://bbs.zhenghui.org/ <p>很好奇Ruby on Rails有什么特色能在Web开发框架中独树一帜？和webwork，struts等web框架相比有什么不同？ </p> http://bbs.zhenghui.org/topic/%e5%87%bd%e6%95%b0%e5%bc%8f%e7%bc%96%e7%a8%8b%e4%b8%80%e9%97%ae#post-146 Mon, 28 Jun 2010 12:25:56 +0000 hui 146@http://bbs.zhenghui.org/ <p>在函数式中函数是first-class citizen，故可直接定义g ＝ f . f，这样g实际上就是一个恒等变换，同时在<strong>形式上</strong>满足了你想要的“先外后内”。至于编译器（或解释器）能否更聪明地直接把g用恒等变换代替，那就归结为函数简化的问题了，而这并非易事（尽管该个例很简单，但难有普适方法）。当然，象LISP这种能进行符号运算（区别于数值运算）的函数式语言，完全可能对一些复合函数通过符号处理来简化。不过，符号处理本身并非函数式的必要特性。</p> <p>另外，如果不考虑效率的话，程序员倒也不用关心这类简化问题，代码的抽象性不会因此而发生变化。 </p> http://bbs.zhenghui.org/topic/%e5%87%bd%e6%95%b0%e5%bc%8f%e7%bc%96%e7%a8%8b%e4%b8%80%e9%97%ae#post-145 Mon, 28 Jun 2010 10:41:56 +0000 Todd 145@http://bbs.zhenghui.org/ <p>f = (x, y) =&gt; (y, x)</p> <p>上面定义了一个函数f，把(x, y)变成(y, x)。如果应用两次该函数则有f(f(x, y)) = (x, y)。这个过程是自内向外的：<br /> f(f(x, y)) = f(y, x) = (x, y)</p> <p>我的问题是：在函数式编程中有没有可能不经过这样的过程，而是自外向内从最外层f开始，先得出f(f) = (x, y) =&gt; (x, y)，然后(f(f))(x, y) = (x, y)来进行？ </p> http://bbs.zhenghui.org/topic/%e5%80%bc%e7%b1%bb%e5%9e%8b%e6%98%af%e5%90%a6%e6%9c%89%e8%a1%8c%e4%b8%ba%ef%bc%9f#post-144 Sat, 26 Jun 2010 15:19:46 +0000 hui 144@http://bbs.zhenghui.org/ <p>很多时候状态与（某些）行为究竟是否该绑定是很难抉择的，这也是许多动态语言都支持mixin的缘故。 </p> http://bbs.zhenghui.org/topic/%e5%80%bc%e7%b1%bb%e5%9e%8b%e6%98%af%e5%90%a6%e6%9c%89%e8%a1%8c%e4%b8%ba%ef%bc%9f#post-143 Sat, 26 Jun 2010 12:42:20 +0000 Todd 143@http://bbs.zhenghui.org/ <p>经过思考我改变了看法，我认为的确应该把值和运算放在一起形成类，这个过程正是数据抽象。值的意义不能脱离运算而单独存在，而运算的意义也是相互联系的，没有+就没有-，+和-必定相互依存。</p> <p>我现在认为对于引用对象具备标识，状态和行为；值对象具备状态和运算。 </p> http://bbs.zhenghui.org/topic/%e5%80%bc%e7%b1%bb%e5%9e%8b%e6%98%af%e5%90%a6%e6%9c%89%e8%a1%8c%e4%b8%ba%ef%bc%9f#post-142 Thu, 24 Jun 2010 20:48:12 +0000 hui 142@http://bbs.zhenghui.org/ <p>运算符重载不仅很多语言不支持，而且许多运算无法对应合理的运算符，因此不是通用的解决办法。至于自由函数，有其灵活的一面，但也不总是最好的选择。从一种意义上说，这是在过程式与对象式之间作选择；从另一种意义上说，这是在系统设计中对模块的职责分配的选择。这里没有一个绝对的胜者。 </p> http://bbs.zhenghui.org/topic/%e5%80%bc%e7%b1%bb%e5%9e%8b%e6%98%af%e5%90%a6%e6%9c%89%e8%a1%8c%e4%b8%ba%ef%bc%9f#post-141 Thu, 24 Jun 2010 20:36:41 +0000 Todd 141@http://bbs.zhenghui.org/ <p>语义上值类型的确可以参与运算，语法上我还是更倾向于使用自由函数或运算符重载。可以把值类型和它所参与的运算定义在一个模块中避免分拆。 </p> http://bbs.zhenghui.org/topic/%e5%80%bc%e7%b1%bb%e5%9e%8b%e6%98%af%e5%90%a6%e6%9c%89%e8%a1%8c%e4%b8%ba%ef%bc%9f#post-140 Thu, 24 Jun 2010 13:01:43 +0000 hui 140@http://bbs.zhenghui.org/ <p>你的这个问题本质上是使用充血对象模型（rich object model）还是该使用贫血对象模型（anemia object model）的问题。显然书中提到的DTO属于后者，而VO则视具体情况而定。Eric Evan认为，在application layer（service layer）中可用后者，而在Domain Layer（Model Layer）中则建议用前者，否则有让对象式滑到过程式之嫌（可以参考Martin Fowler的<a href="http://www.martinfowler.com/bliki/AnemicDomainModel.html">这篇文章</a>），是一种anti-pattern。当然，这也只是一种观点，反方观点同样也有市场。具体选择与实际项目、设计者的偏好以及所用的语言、框架等有关。</p> <p>另外，《冒号课堂》中在提到值类型时，倾向于用运算（operation）而非行为（behavior）来指代对象的方法，毕竟前者的“动感”不如后者，似乎更适用于值类型（值本就是运算的作用对象）。这样你或许更能接受些。</p> <p>举个常见的例子：Money作为一个典型的值类型，你可以说它是一个被动的实体，不应有任何“行为”，但赋予它一些“运算”往往会很方便，比如add（加法运算），exchange（兑换运算）等等。相比把这些运算与Money分拆开来的做法，这种设计通常更简洁、更优雅些。 </p> http://bbs.zhenghui.org/topic/%e5%80%bc%e7%b1%bb%e5%9e%8b%e6%98%af%e5%90%a6%e6%9c%89%e8%a1%8c%e4%b8%ba%ef%bc%9f#post-139 Thu, 24 Jun 2010 11:47:27 +0000 Todd 139@http://bbs.zhenghui.org/ <p>OOP对象3大特征：标识、状态、行为。书中认为值类型具备：状态和行为，而不具备标识。不过，最近我看到一些其他一些资料更强调值类型不具备行为，而是表示状态。我想这是有道理的，因为行为必定要有主体，即标识。所以，我更倾向于从纯语义的角度来看，值类型应该不具备行为。 </p> http://bbs.zhenghui.org/topic/subtype%e5%92%8csubclass#post-138 Thu, 24 Jun 2010 11:22:07 +0000 hui 138@http://bbs.zhenghui.org/ <p>是的，CiteSeerx有大量高质量的学术文章。 </p> http://bbs.zhenghui.org/topic/subtype%e5%92%8csubclass#post-137 Thu, 24 Jun 2010 10:51:55 +0000 Todd 137@http://bbs.zhenghui.org/ <p>CiteSeer是个好地方！ </p> http://bbs.zhenghui.org/topic/%e8%ae%ba%e6%80%9d%e7%bb%b4%e7%9a%84%e5%88%9a%e6%80%a7%e4%b8%8e%e6%9f%94%e6%80%a7#post-136 Wed, 23 Jun 2010 17:11:35 +0000 hui 136@http://bbs.zhenghui.org/ <p>一来最近忙于他事，二来当初写此系列的激情有所减弱，故后续文章迟迟没有动笔，让你久等了，非常抱歉！<br /> 这个系列的内容越写越多，远远超出预计。我会尽量早些把《科学的迷信》下篇完成，但即使这样，离想要表达的主题还有相当一段距离。以后只能见缝插针，慢慢地补全了。<br /> 你推荐的文章有时间我会拜读的，谢谢！</p> <p>另外，本主题不属于《冒号课堂》讨论区，过两天我会把它转移到其他讨论区。 </p> http://bbs.zhenghui.org/topic/%e8%ae%ba%e6%80%9d%e7%bb%b4%e7%9a%84%e5%88%9a%e6%80%a7%e4%b8%8e%e6%9f%94%e6%80%a7#post-135 Wed, 23 Jun 2010 16:48:59 +0000 fu826701 135@http://bbs.zhenghui.org/ <p>郑老师写地很好，只是没有下篇，读的正是兴奋的时候泼了一瓢凉水，很不尽兴！期待下篇，另外，对于郑老师，有时间的话看看何新学者的《我的哲学思考：方法与逻辑》，我觉得他在思想逻辑上很有见解！ </p> 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/ <p>范畴理论是数学中抽象代数（abstract algebra）的一个分支，主要是以最抽象的方式研究数学结构以及它们之间的关系。 每个范畴（category）包括一组对象（object），一组态射（morphism），以及态射之间的合成。 对应于程序中的类型系统，这组对象可以看成某个数据类型所涵盖的所有对象，而态射则可以看成函数，态射合成对应于函数合成。在函数式语言Haskell中，这种对应更加清晰，而且Haskell中的functor和monad都直接来源于范畴理论中对应的概念。<br /> 更详细的可以参考：<br /> <a href="http://en.wikipedia.org/wiki/Category_theory" rel="nofollow">http://en.wikipedia.org/wiki/Category_theory</a><br /> <a href="http://en.wikibooks.org/wiki/Haskell/Category_theory" rel="nofollow">http://en.wikibooks.org/wiki/Haskell/Category_theory</a></p> <p>从这里也看出，高级的数学知识对从更抽象和更高层的角度来理解编程是有意义的。但不是所有的人都习惯数学的思维方式，所以对一般程序员我并不推荐深入地学习，这种素养的培养比编程要困难得多。 </p> 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/ <p>记得郑老师曾经讲过范畴论(category theory)和程序类型系统是相通的，但是后者要简单得多。我想了解范畴论是讲什么的，尤其是还涉及了哪些方面是一般程序类型系统没有的？ </p> http://bbs.zhenghui.org/topic/subtype%e5%92%8csubclass#post-132 Mon, 14 Jun 2010 17:40:53 +0000 Todd 132@http://bbs.zhenghui.org/ <p>是的，和《冒号课堂》的观点基本一致。区分了subtype和subclass就能把继承和多态的关系理清楚了。同时，对于以前不太容易区分的interface与abstract class的选择问题也会更清楚。使用interface是为了subtype，使用abstract class则包含了subtype和subclass。记得书中比喻abstract class是半成品。 </p> http://bbs.zhenghui.org/topic/subtype%e5%92%8csubclass#post-131 Mon, 14 Jun 2010 00:36:52 +0000 hui 131@http://bbs.zhenghui.org/ <p>非常好的文章，多谢分享。其中谈到subclass与subtype的区别时是这样说的：Subclasses allow one to reuse the code inside classes - both instance variable declarations and method definitions. Thus they are useful in supporting code reuse inside a class. Subtyping on the other hand is useful in supporting reuse externally, giving rise to a form of polymorphism。即：子类用于类的内部重用，子类型用于外部重用。这个与《冒号课堂》中提到的观点本质上是一致的：实现继承消费可重用的旧代码，接口继承生产可重用的新代码；接口继承不是为了代码重用，而是为了代码被重用。</p> <p>另：该文章的PDF版可到 <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.9.7539&amp;rep=rep1&amp;type=pdf" rel="nofollow">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.9.7539&amp;rep=rep1&amp;type=pdf</a> 下载。 </p>