http://bbs.zhenghui.org/forum/colonclass-discussion 冒号论坛 » Forum: 《冒号课堂》讨论区 - Recent Posts en-US Wed, 08 Sep 2010 12:47:03 +0000 http://bbpress.org/?v=1.0.2 q http://bbs.zhenghui.org/search.php http://bbs.zhenghui.org/topic/dbc%e5%92%8ctdd#post-188 Tue, 07 Sep 2010 19:40:14 +0000 hui 188@http://bbs.zhenghui.org/ <p>虽然assertion中不能含有副作用的语句，但DbC中的precondition和postcondition之间是允许副作用的。当然不可否认，DbC的表达力的确是有局限的。 </p> http://bbs.zhenghui.org/topic/dbc%e5%92%8ctdd#post-187 Tue, 07 Sep 2010 17:41:15 +0000 Todd 187@http://bbs.zhenghui.org/ <p>需求的表达方式有很多种： 自然语言文档，UML用例图，TDD的测试用例，DBC的契约。好的需求规范应该追求精确性和抽象（通用）性。自然语言和UML用例图具备抽象性，但精确性不足；TDD的测试用例具备精确性但没有抽象性；DBC同时具备这两个特征但是表达能力不足，不是所有规范都能用无副作用的语句来表示。 </p> http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-186 Sat, 04 Sep 2010 16:00:11 +0000 Todd 186@http://bbs.zhenghui.org/ <p>谢谢，推荐的文章很好，看了之后我对LoD的认识加深了不少！</p> <p>另外，还有一个意外的收获，即文中提到了CQRS。以前我觉得很多post condition/class invariant不容易在实际编程中表达，一个重要原因是assert语句不应该有副作用，现在我知道如果类的设计能采用CQRS的方式，那么就很容易写出无副作用的assert语句来表达post condition/class invariant。</p> <p>另外，最近关于CQRS还看到一些持久化方面的应用，普通的持久化方案是基于对象内部状态的，而采用CQRS，把所有的commands持久化下来就得到了对象的状态以及状态历史。 </p> http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-185 Sat, 04 Sep 2010 00:19:36 +0000 hui 185@http://bbs.zhenghui.org/ <p>迪米特法则（以下简称LoD）提倡一个类尽量不要与其间接关联的类发生直接对话。这一方面有助于减少类之间的关联，从而降低系统的耦合度；另一方面有助于界定职责范围，从而增强了系统的内聚度。从消息传递的角度看，LoD可看作一种对象交流原则：<em>只吩咐不询问</em>（tell, don't ask)（可参见 <a href="http://www.pragprog.com/articles/tell-dont-ask" rel="nofollow">http://www.pragprog.com/articles/tell-dont-ask</a> 和 <a href="http://www.c2.com/cgi/wiki?TellDontAsk" rel="nofollow">http://www.c2.com/cgi/wiki?TellDontAsk</a> ）。当然，LoD最终目的是为了降低软件的脆弱性、增强软件的可维护性。</p> <p>LoD虽然不是必须遵守的铁律，但一个有经验的程序员在违背它时，会听到身后的警告声：你知道得太多了：） </p> http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-184 Fri, 03 Sep 2010 22:00:29 +0000 Todd 184@http://bbs.zhenghui.org/ <p>目前，我能够识别并避免违背迪米特法则，但是总感觉对迪米特法则的认识深度还不够，还不能说清楚到底迪米特法则本质上意味着什么。我目前思考的结果是：<br /> OOP中，对象间的交互是消息传递模型，而消息是值语义的；而obj.GetAnotherObject()的结果是引用，违背了对象消息传递模型。所以，违背迪米特法则的设计其实是不符合OOP的。 </p> 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/ <p>一元思维是刚性的，多元思维是柔性的。 </p> 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/ <p>佛教里面最大的一部经《华严经》讲宇宙是多元的，以前不懂，现在从UML中受到启发，似乎有点儿明白了。 </p> http://bbs.zhenghui.org/topic/%e8%af%b7%e6%8e%a8%e8%8d%90%e4%b8%80%e6%9c%ac%e4%b9%a6#post-181 Tue, 31 Aug 2010 16:37:34 +0000 hui 181@http://bbs.zhenghui.org/ <p>库恩的《The Structure of Scientific Revolutions》（英文版： <a href="http://book.douban.com/subject/1417091/" rel="nofollow">http://book.douban.com/subject/1417091/</a> 中文版： <a href="http://book.douban.com/subject/1123740/" rel="nofollow">http://book.douban.com/subject/1123740/</a> ）是一本科学哲学的名著，编程范式中的”范式（paradigm）“就是来源于这本书中提出的核心思想——paradigm shift。此书短小精悍，颇有启发性。<br /> 如果要看对科学更为完整概述的书，推荐丹皮尔的《科学史》（ <a href="http://book.douban.com/subject/4712530/" rel="nofollow">http://book.douban.com/subject/4712530/</a> ），该书不仅介绍了科学史，还着重论述了科学、哲学与宗教之间的关系。<br /> 在数学上推荐克莱因的名著《古今数学思想》，虽然有四册，但非常值得认真研读。 </p> http://bbs.zhenghui.org/topic/%e8%af%b7%e6%8e%a8%e8%8d%90%e4%b8%80%e6%9c%ac%e4%b9%a6#post-180 Tue, 31 Aug 2010 16:02:42 +0000 Todd 180@http://bbs.zhenghui.org/ <p>《冒号课堂》的编程范式部分是从宏观上介绍了程序设计语言的概貌，我想知道有没有一本数学或者科学方面的书籍能起到类似的效果，即建立一些宏观的概念，介绍一些思想。 </p> http://bbs.zhenghui.org/topic/%e5%80%bc%e4%b8%8e%e5%bc%95%e7%94%a8#post-179 Tue, 10 Aug 2010 18:16:59 +0000 Todd 179@http://bbs.zhenghui.org/ <p>我那篇博文的观点只是引用《冒号课堂》而已。我读到值与引用这章觉得受益匪浅，但可惜不是所有人都认得好东西，黄金摆在面前以为是泥巴。 </p> http://bbs.zhenghui.org/topic/%e5%80%bc%e4%b8%8e%e5%bc%95%e7%94%a8#post-178 Tue, 10 Aug 2010 17:57:06 +0000 hui 178@http://bbs.zhenghui.org/ <p>这篇文章的中心是：选择值与引用，应主要从语义的角度，而不是从实现的角度（包括性能考量）。这正好支持了你的那篇颇受争议的博文中的观点。 </p> http://bbs.zhenghui.org/topic/%e5%80%bc%e4%b8%8e%e5%bc%95%e7%94%a8#post-177 Tue, 10 Aug 2010 17:35:00 +0000 Todd 177@http://bbs.zhenghui.org/ <p>这篇文章写得不错，可以作为学习值与引用的参考：</p> <p><a href="http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-stack-is-an-implementation-detail.aspx" rel="nofollow">http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-stack-is-an-implementation-detail.aspx</a> </p> http://bbs.zhenghui.org/topic/%e8%af%ad%e8%a8%80%e4%b8%8e%e6%80%9d%e7%bb%b4#post-176 Sun, 08 Aug 2010 15:40:43 +0000 hui 176@http://bbs.zhenghui.org/ <p>以后出现新范式上完全可能的，而且可能性极大。你问的“发现提出新范式”如果是指如何提出新范式，那我就不敢回答了，因为本人没有提出过新范式:) 如果是指如何发现他人提出新范式，这就要靠平时多关注业界动态了。另外，范式通常通过语言（有时也通过框架或库）来体现的，多关注这方面的信息会更早地获得编程范式的动向。 </p> http://bbs.zhenghui.org/topic/%e8%af%ad%e8%a8%80%e4%b8%8e%e6%80%9d%e7%bb%b4#post-175 Sat, 07 Aug 2010 23:48:06 +0000 Todd 175@http://bbs.zhenghui.org/ <p>以后会不会再出现新的范式呢？怎样才能发现提出新范式呢？ </p> http://bbs.zhenghui.org/topic/%e8%af%ad%e8%a8%80%e4%b8%8e%e6%80%9d%e7%bb%b4#post-174 Sat, 07 Aug 2010 19:58:43 +0000 hui 174@http://bbs.zhenghui.org/ <p>《冒号课堂》强调编程范式，并分析编程语言各自的长短，正是为了开阔编程思路，不要囿于某一种编程范式或编程语言。对于一个具体的问题，通常可以用不同的编程范式、不同的编程语言来解决，但在难易度、简洁度、运行效率等方面往往有相当的差别。关于各自范式的擅长领域、常见应用等可参见《冒号课堂》P105的表格。由于现代的流行语言通常支持多种范式，即使不天然支持，也多有相应的库或框架，或者自行构建也是完全有可能的。因此，只要重点掌握少量的语言，同样可以吸取不同的编程思想的精华。 </p> http://bbs.zhenghui.org/topic/%e8%af%ad%e8%a8%80%e4%b8%8e%e6%80%9d%e7%bb%b4#post-173 Sat, 07 Aug 2010 15:39:23 +0000 Todd 173@http://bbs.zhenghui.org/ <p>以前听说过语言对思维的影响，不大理解。但在计算机领域，程序设计语言对思维的影响确实是显而易见的，只会用C的程序员多半是过程思维，在不学习OOP的情况下，很难形成OO思维。而多数程序员不了解函数式编程也是同样的道理。用一句有名的话“当你手中只有一把锤子的时候，你看任何东西都是钉子”可能就是这个道理。</p> <p>我现在最感兴趣的不是“语言对思维有影响”这个事实，而是既然每个人掌握的语言都总是有限的，即使精通所有程序设计语言，也不能保证以后不出现新的语言代表新的思维和范式。那么，如何才能立足于现有的语言，又能跳出语言所形成的固有思维定势呢？ </p> http://bbs.zhenghui.org/topic/%e5%85%b3%e4%ba%8e%e5%90%88%e6%88%90%e7%9a%84%e5%9f%ba%e7%a1%80%e7%b1%bb%e9%97%ae%e9%a2%98#post-172 Wed, 04 Aug 2010 23:58:33 +0000 hui 172@http://bbs.zhenghui.org/ <p>难得你这么认真，请多提意见，谢谢! </p> http://bbs.zhenghui.org/topic/%e5%85%b3%e4%ba%8e%e5%90%88%e6%88%90%e7%9a%84%e5%9f%ba%e7%a1%80%e7%b1%bb%e9%97%ae%e9%a2%98#post-171 Wed, 04 Aug 2010 23:53:32 +0000 whlgh 171@http://bbs.zhenghui.org/ <p>谢谢郑老师，这本书我正在看第三遍，每一遍的感觉都不一样。 </p> http://bbs.zhenghui.org/topic/%e5%85%b3%e4%ba%8e%e5%90%88%e6%88%90%e7%9a%84%e5%9f%ba%e7%a1%80%e7%b1%bb%e9%97%ae%e9%a2%98#post-170 Wed, 04 Aug 2010 23:04:35 +0000 hui 170@http://bbs.zhenghui.org/ <p>合成的基础类（underlying class）是指构成一个（合成）类的那些组件（component）类。比如：<br /> class A { ... }<br /> class B { ... }<br /> class C<br /> {<br /> private A a = new A();<br /> private B b = new B();<br /> ...<br /> }</p> <p>其中，类A和类B就是类C的基础类。它们不能是抽象类型是因为它们的对象创建必须由类C负责，否则就不是合成（composition）关系而是聚合（aggregation）关系。（合成与聚合的区别请参见本书第334页：合成是基于值语义的包含，聚合是基于引用语义的包含） </p> http://bbs.zhenghui.org/topic/%e5%85%b3%e4%ba%8e%e5%90%88%e6%88%90%e7%9a%84%e5%9f%ba%e7%a1%80%e7%b1%bb%e9%97%ae%e9%a2%98#post-169 Wed, 04 Aug 2010 22:22:41 +0000 whlgh 169@http://bbs.zhenghui.org/ <p>郑老师，你好，我在书上第294页讲合成的缺点时，看到一句话这么说：“合成的基础类只能是具体类型，不能是抽象类型”，请问合成的基础类是什么意思？为什么不能是抽象类型？能不能再详细讲解一下，谢谢。 </p> 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/ <p>SICP上提到：与任何复杂系统一样，分层(Hierarchy)是一种应对软件复杂性的组织方式。 </p> 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/ <p>关于软件开发的过程（暂不考虑软件测试和维护）一般的说法（以waterfall模型为代表）是：分析用户需求 =&gt; 提炼出合乎需求的规范 =&gt; 根据规范进行设计 =&gt; 编写代码实现设计。这种描述过于粗线条了，实际的开发过程往往是上层需求产生下层设计，在实现该设计的过程中又产生更下层的需求...正是你上面所描述的情形。不出意外地，在这里我们又看问题的关键仍然是：如何将复杂的问题合理地进行抽象分层。 </p> 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/ <p>最近在学习TDD的过程中，我对需求与设计的关系进行了一些思考，我发现：系统A的<strong>需求</strong>决定了A的外部特征，这是系统A不变的部分；系统A的<strong>设计</strong>是如何将A划分为有关联的若干子系统a1,a2...an，这就是系统A的可变部分；系统A的设计又转化为对其子系统a1,a2,...an的<strong>需求</strong>。如果把视野扩宽，系统A的需求也必然产生于更大的系统中的设计。所以，软件需求是来源于更高层次的设计的。对于软件来说产品设计处于最高层，产品设计来源于对用户需求的理解（可能并不明确，需要自己探索）。 </p> 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>