http://bbs.zhenghui.org/ 冒号论坛 » Recent Posts en-US Wed, 08 Feb 2012 22:30:46 +0000 http://bbpress.org/?v=1.0.2 q http://bbs.zhenghui.org/search.php http://bbs.zhenghui.org/topic/%e6%95%b0%e6%8d%ae%e5%92%8c%e4%bb%a3%e7%a0%81#post-362 Wed, 26 Oct 2011 15:59:08 +0000 Todd 362@http://bbs.zhenghui.org/ <p>谢谢，学习中... </p> http://bbs.zhenghui.org/topic/%e6%95%b0%e6%8d%ae%e5%92%8c%e4%bb%a3%e7%a0%81#post-361 Tue, 25 Oct 2011 19:59:21 +0000 hui 361@http://bbs.zhenghui.org/ <p>通常所谓的“代码即数据”并非你所说的意思，而是指一种语言有这样的特性：其中的代码本身也是一种first-class的数据结构，可以作为数据来处理。最著名的支持该特性的是Lisp及其衍生语言（如clojure)，其代码与数据均由S-expression表示。此外，还有Prolog等语言也支持该特征。在学术上，这被称为Homoiconicity ，相关简介可参见<a href="http://en.wikipedia.org/wiki/Homoiconicity" rel="nofollow">wiki</a>、<a href="http://c2.com/cgi/wiki?HomoiconicLanguages" rel="nofollow">c2.com</a>。 </p> http://bbs.zhenghui.org/topic/%e6%95%b0%e6%8d%ae%e5%92%8c%e4%bb%a3%e7%a0%81#post-360 Tue, 25 Oct 2011 18:09:10 +0000 Todd 360@http://bbs.zhenghui.org/ <p>最近体会到抽象数据类型是用代码实现了数据的性质，所以是“代码即数据”的体现，不知道是否正确？ </p> http://bbs.zhenghui.org/topic/%e5%af%b9%e8%b1%a1%e7%9a%84%e6%b6%88%e6%81%af%e6%a8%a1%e5%9e%8b#post-354 Thu, 08 Sep 2011 08:27:28 +0000 hui 354@http://bbs.zhenghui.org/ <p>嗯，这个解释应当是比较直观和容易理解的。动态类型语言之“动态”所在，是类型之动态，因此在运行前检查类型毫无意义；动态语言之“动态”，是语言之动态，因此对象/类的方法、属性等是可能在运行期间改变的。你提到的这篇文章解释了一件事情：对于一个静态类型的动态语言（如scala、groovy），虽然在运行前应当检查类型但有时并非如此，原因是：其动态语言的特征决定了有些method call的dispatch在运行前并不确定，因此无法检查参数类型。 </p> http://bbs.zhenghui.org/topic/%e5%af%b9%e8%b1%a1%e7%9a%84%e6%b6%88%e6%81%af%e6%a8%a1%e5%9e%8b#post-341 Tue, 06 Sep 2011 22:58:22 +0000 Todd 341@http://bbs.zhenghui.org/ <p>关于动态语言与动态类型语言的区别，今天看了这篇文章才稍微明白一点：<a href='http://groovy.dzone.com/news/dynamic-typing-vs-dynamic-lang' rel="nofollow">Dynamic Typing vs Dynamic Language Explained</a>。我理解动态类型语言是指同一个名称可以动态绑定到不同类型的对象上，比如：<br /> a = 1;<br /> a = 'test'；</p> <p>而动态语言可能是非动态类型的，比如a只能绑定到一种对象类型，但是可以动态添加删除修改方法和属性，方法的调用是动态分派的：<br /> A a = new A();<br /> a.f = function() { ... }<br /> a.f()</p> <p>不知道理解是否正确？ </p> http://bbs.zhenghui.org/topic/%e5%a6%82%e4%bd%95%e7%9c%8b%e5%be%85stl%e7%9a%84stack#post-338 Fri, 02 Sep 2011 17:44:18 +0000 Todd 338@http://bbs.zhenghui.org/ <p>&gt;&gt;一个类型究竟是引用语义还是值语义，不仅与类型本身有关，也与所用的场合有关。</p> <p>我也是这样想的。事物本身没有绝对的值语义还是引用语义，在建模的时候我们可以根据需要采用不同的语义模型。在实现上，受语言的限制难免会有副作用，这是需要根据语义小心使用。 </p> http://bbs.zhenghui.org/topic/%e5%a6%82%e4%bd%95%e7%9c%8b%e5%be%85stl%e7%9a%84stack#post-337 Fri, 02 Sep 2011 15:37:21 +0000 hui 337@http://bbs.zhenghui.org/ <p>这个并不奇怪。首先，如果只在乎标识，直接比较两个container对象的指针（地址）即可，重载==进行内容比较是额外的福利。其次，即使对同一个类型的container，尽管是引用语义，但在某些场合也可能非常关注其内容。比如，Set是一种container，对于两个Set对象，我们可能需要比较它们内容之间的关系，如用operator==来判断两个集合是否值相同，用operater&lt;和operator&gt;结合不同的comparator来进行子集排序、字典排序等等。这就好比两个不同的人，本身应该是引用语义的，但有时我们会比较他们的值，比如身高、体重、速度等等，甚至在一定context下只要我们所关心的值是相等的，便认为他们是可以互换的（interchangeable），此时实际上已经是值语义了。<br /> 换言之，一个类型究竟是引用语义还是值语义，不仅与类型本身有关，也与所用的场合有关。 </p> http://bbs.zhenghui.org/topic/%e5%a6%82%e4%bd%95%e7%9c%8b%e5%be%85stl%e7%9a%84stack#post-336 Fri, 02 Sep 2011 12:53:03 +0000 Todd 336@http://bbs.zhenghui.org/ <p>STL container重载==进行内容比较这点不是很好理解。既然是引用语义的相等性是基于标识的，那么为什么要重载==进行内容比较呢？ </p> http://bbs.zhenghui.org/topic/%e5%a6%82%e4%bd%95%e7%9c%8b%e5%be%85stl%e7%9a%84stack#post-335 Fri, 02 Sep 2011 09:24:40 +0000 hui 335@http://bbs.zhenghui.org/ <p>首先，你的问题可以推广到STL的一切container类，而不必限于stack类。<br /> 其次，所有container类都是引用语义的。原因很简单，虽然container允许复制，但复制后的两个container是各自独立变化的，而且其标识是有显著意义的（引用语义!=noncopyable）。<br /> 最后，虽然STL中的container类本身是引用语义的，但其运算却是基于值语义的。为何如此设计呢？一个简单的答案是：C++中的array便是如此的（ ISO C++ standard：no arrays of references），如果STL中的container的用法与最基本的数组不同，显然有违直觉的。稍微复杂的说明如下：<br /> 假设container的运算是基于引用语义的。<br /> Container c1, c2;<br /> Element el;<br /> c1.insert(el);<br /> c2.insert(el);<br /> 此时如果改变c1中el的值，将会同时改变c2中el的值，而这未必是设计者的初衷。<br /> 再假设：<br /> Container c;<br /> {<br /> Element el;<br /> c.insert(el);<br /> }<br /> ...// 此时el出了有效范围，将被析构，那么c岂不是含有了一个illegal的元素？</p> <p>如果用户的确需要引用语义的container运算呢？很简单，让container的运算作用于element对象的指针即可。但这时就要特别注意element对象的生命周期问题了。 </p> http://bbs.zhenghui.org/topic/%e5%a6%82%e4%bd%95%e7%9c%8b%e5%be%85stl%e7%9a%84stack#post-334 Thu, 01 Sep 2011 21:16:55 +0000 Todd 334@http://bbs.zhenghui.org/ <p>STL的stack类的对象有标识，有状态，有行为，符合引用语义；而stack又允许拷贝构造，同时相等性比较又重载了==进行值比较，符合值语义。那么从值和引用的角度，我们应该如何看待STL的stack呢？ </p> http://bbs.zhenghui.org/topic/%e5%af%b9%e8%b1%a1%e7%9a%84%e6%b6%88%e6%81%af%e6%a8%a1%e5%9e%8b#post-333 Mon, 15 Aug 2011 15:23:34 +0000 Todd 333@http://bbs.zhenghui.org/ <p>应该是书上介绍过，但我没有留下什么印象，一直没有加以区别。 </p> http://bbs.zhenghui.org/topic/%e5%af%b9%e8%b1%a1%e7%9a%84%e6%b6%88%e6%81%af%e6%a8%a1%e5%9e%8b#post-332 Sun, 14 Aug 2011 23:06:08 +0000 hui 332@http://bbs.zhenghui.org/ <p>看来是《冒号课堂》中的叙述还不够清晰？动/静态类型语言的区别在于类型检查的时间：前者在编译期（或运行之前），后者在运行期。动/静态语言的区别是：前者的代码行为可能在运行时改变（比如类的方法、属性的增减或修改），后者则不可能。 </p> http://bbs.zhenghui.org/topic/%e5%af%b9%e8%b1%a1%e7%9a%84%e6%b6%88%e6%81%af%e6%a8%a1%e5%9e%8b#post-331 Sun, 14 Aug 2011 22:48:16 +0000 Todd 331@http://bbs.zhenghui.org/ <p>其实，我对“静/动态语言”和“静/动态类型语言”的区别不是很清楚。郑老师认为二者的区别是什么呢？ </p> http://bbs.zhenghui.org/topic/%e5%af%b9%e8%b1%a1%e7%9a%84%e6%b6%88%e6%81%af%e6%a8%a1%e5%9e%8b#post-330 Sun, 14 Aug 2011 22:21:00 +0000 hui 330@http://bbs.zhenghui.org/ <p>文章写得挺好的，抓住了消息模型的特征。有一个小问题，你在文章和此处一再提到“静态类型语言”与“动态类型语言”的差别，但其实这更多的是“静态语言”与“动态语言”的差别。正是因为动态语言有可能在运行时改变对象的方法，才使得诸如“Method Missing"的特征熠熠生辉。 </p> http://bbs.zhenghui.org/topic/%e5%af%b9%e8%b1%a1%e7%9a%84%e6%b6%88%e6%81%af%e6%a8%a1%e5%9e%8b#post-329 Sun, 14 Aug 2011 18:15:02 +0000 Todd 329@http://bbs.zhenghui.org/ <p>以前我主要接触的静态类型语言，现在接触了动态语言之后对于对象的消息模型又有了一些新的理解。今天把理解写出了出来，请郑老师看看，谢谢！http://www.cnblogs.com/weidagang2046/archive/2011/08/14/2138059.html </p> http://bbs.zhenghui.org/topic/%e4%bb%8e%e6%95%b0%e6%8d%ae%e4%ba%b2%e5%92%8c%e5%8a%9b%e8%a7%92%e5%ba%a6%e7%9c%8b%e8%af%ad%e8%a8%80#post-328 Thu, 07 Jul 2011 16:41:39 +0000 Todd 328@http://bbs.zhenghui.org/ <p>C/C++对Unicode的确很不友好，这个在应用层开发中是个大问题。 </p> http://bbs.zhenghui.org/topic/%e4%bb%8e%e6%95%b0%e6%8d%ae%e4%ba%b2%e5%92%8c%e5%8a%9b%e8%a7%92%e5%ba%a6%e7%9c%8b%e8%af%ad%e8%a8%80#post-327 Thu, 23 Jun 2011 10:15:06 +0000 hui 327@http://bbs.zhenghui.org/ <p>数据的亲和力是个很好的视角。它与语言的范式关系不大，主要与语言的设计目的有关。C是系统语言，自然需要方便而高效地对内存数据进行操作。Javascript是网页操作语言，由于远离系统，同时对开发者的要求较为宽松，对数据类型的严格性要求较低，故被设计为动态语言和动态类型语言。JSON本就是为它设计的，二者的相容性自然高。Shell（包括perl、python等）的用途决定了它是一个粘合语言，必然要求对文本形式的数据的强亲和力。Lisp号称列表处理语言，自然对list类型的数据亲和力高。<br /> 数据亲和力是语言的一个重要指标，因为亲和力越强编程效率越高。在这方面，早期的语言通常不如后来的语言。比如C、C++对unicode数据的亲和力就不如后来的Java和C＃，Perl、Python等早期版本对unicode的亲和力就不如后期版本。又如，早期语言对XML、HTML数据的处理需要通过库，而Groovy等语言则已经内生支持它们了（C#、Java等语言也有此趋势）。再如，Perl、Ruby、Python、PHP等“敏捷”语言对list、map等常用类型的亲和力也比一般语言要强。 </p> http://bbs.zhenghui.org/topic/%e4%bb%8e%e6%95%b0%e6%8d%ae%e4%ba%b2%e5%92%8c%e5%8a%9b%e8%a7%92%e5%ba%a6%e7%9c%8b%e8%af%ad%e8%a8%80#post-326 Wed, 22 Jun 2011 20:59:24 +0000 Todd 326@http://bbs.zhenghui.org/ <p>最近我对程序设计语言又有了一些新的体会，大致说来是从数据处理的角度来看待语言的差异。我抽象出了一个概念-“数据亲和力（Data Affinity)”，它指的是语言的数据模型与某种数据形式之间的匹配程度。数据亲和力也是决定语言适用于哪些应用场合的重要因素。比如：<br /> 1. C语言的struct（语言的数据模型）和字节块（数据形式）之间可以建立起直接的映射关系，所以C语言具有较高的对字节块形式数据的亲和力，适用于需要进行直接内存操作的底层应用；<br /> 2. Javascript的对象（语言的数据模型）和JSON数据（数据形式）之间可以非常方便的相互转换，所以Javascript具有较高的对JSON数据的亲和力，适用于在分布式系统之间用JSON进行通信；<br /> 3. Shell对文本流形式的数据和文件具有较高的数据亲和力，适用于文本处理和文件操作应用.</p> <p>我发现数据亲和力和语言的范式没有必然的联系，比如：一门语言是面向过程的并不意味着它拥有对字节块形式数据的亲和力；一门语言是OOP的也不意味着它有对JSON数据的亲和力。根本上讲，数据亲和力取决于语言的数据模型，但也可能会和语言的强/弱类型、动/静类型有关系。C语言拥有字节块亲和力用到了弱类型特性；Javascript拥有JSON亲和力的关键是其动态类型。</p> <p>除了上面的例子，像SQL这样的DSL更是专门针对一种数据模型而量身定做的，所以DSL通常也会表现出某种数据亲和力。 </p> 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/ <p>我看了您推荐的读物,不得不说我仍然认为将迭代抽象与其它4者相提并论欠妥..<br /> 就好比..我们不会给书增加一个新的章节,叫'IO抽象',然后给出文件流抽象之类的例子,并配以"IO抽象使得程序员不必关心诸如缓冲之类的事,只需与逻辑上的Stream打交道"之类的陈述 </p> 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/ <p>同感,迭代更像是其他抽象的一个应用,先看看上面的资料... </p> http://bbs.zhenghui.org/topic/%e6%88%90%e5%91%98%e5%87%bd%e6%95%b0%e7%9a%84%e6%9e%b7%e9%94%81#post-323 Wed, 01 Jun 2011 16:48:15 +0000 Lumj 323@http://bbs.zhenghui.org/ <p>嗯,对,我就是觉得这带来了额外的限制,而且,这意味着语言特性设计的不正交吧 </p> http://bbs.zhenghui.org/topic/%e6%88%90%e5%91%98%e5%87%bd%e6%95%b0%e7%9a%84%e6%9e%b7%e9%94%81#post-322 Wed, 01 Jun 2011 14:02:34 +0000 hui 322@http://bbs.zhenghui.org/ <p>原来你说的是这个意思。没错，这种情况用自由函数（free function）（即你所说的普通函数）肯定是更好，但不是所有的OOP语言都支持的（比如Java、C#）。如果是你所说的情况，哪怕不涉及多态问题，这类操作也应作为自由函数或者某个utility类的静态方法。<br /> 至于如何解决你提到的多态问题，《冒号课堂》430－434页其实已经给出了一个答案：在语法不支持多分派（multiple dispatch）的OOP语言中，可以采用visitor模式，既可避免不必要的耦合，又可避免类型判断。 </p> http://bbs.zhenghui.org/topic/%e6%88%90%e5%91%98%e5%87%bd%e6%95%b0%e7%9a%84%e6%9e%b7%e9%94%81#post-321 Wed, 01 Jun 2011 13:14:33 +0000 Lumj 321@http://bbs.zhenghui.org/ <p>可是我想操作以成员函数的方式存在并不总是令人满意的吧,比如,如果不考虑多态的问题,在写一个类的时候,有时就会选择把有些'操作'写成普通的函数<br /> "这个操作的逻辑是使用A对象的上下文的逻辑,A对其的知情根本就没有意义"<br /> 是指,比如,有个Complex class,现在使用者希望把Complex对象存入文件,而Complex的开发者并没有直接提供这些,因为他认为Complex还需要去了解FileStream太奇怪了(Complex.ToFile(FileStream)),Complex应该只完成它的份内事,构造,计算,等等.ToFile不是带来了不必要的耦合吗?<br /> 在Complex类外写一个(不论是Complex的开发者还是使用者)ToFile不是更合理吗?(ToFile(FileStream,Complex))这样Complex和File就完全无关了(开发Complex的人完全不需要了解FileStream) </p> http://bbs.zhenghui.org/topic/%e6%88%90%e5%91%98%e5%87%bd%e6%95%b0%e7%9a%84%e6%9e%b7%e9%94%81#post-320 Tue, 31 May 2011 23:32:12 +0000 hui 320@http://bbs.zhenghui.org/ <p>&gt;&gt;现在对A类型的变量的某种操作需要多态(对X,Y有不同的做法),那么这样的限制就逼迫人把该操作写成A的成员函数</p> <p>既然存在“对A类型的变量的某种操作”，那么把该操作写成A的成员函数不是很自然吗？假如该操作对X、Y有不同的做法，但又属于一类操作，将其抽象为一个成员函数不是正好吗？假如该操作在X、Y中没有统一的规范，那可以把它们看作完全不相干的两件事，不是吗？ </p> http://bbs.zhenghui.org/topic/%e6%88%90%e5%91%98%e5%87%bd%e6%95%b0%e7%9a%84%e6%9e%b7%e9%94%81#post-319 Tue, 31 May 2011 19:37:53 +0000 Lumj 319@http://bbs.zhenghui.org/ <p>大多OO语言对多态的支持,都限定了多态能力的使用方法,即,要使一个操作多态,它必须以成员函数的形式存在<br /> ——对了,说明:指动态的类型多态,GP不算(也就是老师你的书里说的..'inclusion poly')<br /> 我在最近的开发中发现这似乎很容易带来设计枷锁:<br /> 有时,想做的仅仅是以类型为指标来作分派,但是这就(由于语言提供的接口的限制)必须走那条唯一的途径:通过成员函数.但是我想这前后两者是没有必然联系的,至少从可行性(语义的合理性,实现的可能性)上说一样可以通过游离函数来做<br /> 假设有A,然后X,Y都继承A,现在对A类型的变量的某种操作需要多态(对X,Y有不同的做法),那么这样的限制就逼迫人把该操作写成A的成员函数,但是这有可能是违背当前的设计场合的.比如,这个操作的逻辑是使用A对象的上下文的逻辑,A对其的知情根本就没有意义,那么要么就通过成员函数被强迫耦合,要么就自己写类型判断分派<br /> 不知我的表达是否清楚? </p> http://bbs.zhenghui.org/topic/%e5%85%b3%e4%ba%8e%e7%bb%a7%e6%89%bf#post-318 Tue, 31 May 2011 19:13:59 +0000 Lumj 318@http://bbs.zhenghui.org/ <p>"如果父类有protected域成员却无相应的规范文档，这种父类不要也罢"<br /> 哈哈<br /> 我觉得其实父类直接向子类暴露数据(protected),和一个类直接向外部暴露它的数据(public),定性地来看,是一样的,只是前者从名义上来说更容易套近乎——"hi,我也是写类供外面使用的"——从而对它的松懈觉得情有可原罢了,而实际上它对父类的颠覆能力一点也不差.. </p> http://bbs.zhenghui.org/topic/%e5%85%b3%e4%ba%8e%e7%bb%a7%e6%89%bf#post-317 Tue, 10 May 2011 18:41:37 +0000 hui 317@http://bbs.zhenghui.org/ <p>现实中子类采用父类protected域成员的情形的确有不少，但这种设计一般是不提倡的。这是因为相比方法成员，域成员的可变性更大，包括名称、用法、访问控制等等，并且也不像前者那样可以被overriden。此外，其用法的粒度也大于前者的粒度。总之，后者的抽象性和规范性均不如前者。这也是为什么接口都以方法成员而非域成员的形式出现的原因。<br /> 话说回来，一旦父类已经采用了protected域成员，也不是绝对不能在子类中引用的。但要注意两点：一、如果不通过域成员也能达到目的的，则尽量不用，除非涉及到严重的性能问题；二、如果不得不用，一定要弄清域成员的详细规范并严格遵循之。（如果父类有protected域成员却无相应的规范文档，这种父类不要也罢） </p> http://bbs.zhenghui.org/topic/%e5%85%b3%e4%ba%8e%e7%bb%a7%e6%89%bf#post-316 Tue, 10 May 2011 18:22:31 +0000 folger 316@http://bbs.zhenghui.org/ <p>有个小问题,请老师指教.</p> <p>在第九章讲继承时,您有这么一个观点,父类应该尽可能禁用protected域成员.我想知道什么情况下可以违背这一原则.因为现实中这种情况似乎非常普遍:父类中含有需要和子类共享而又不便为外界所知的数据,这时候难道不是将其设为protected更为合适吗? </p> http://bbs.zhenghui.org/topic/%e5%8f%98%e9%87%8f%e4%b8%8e%e5%87%bd%e6%95%b0lazy-eager#post-315 Sat, 30 Apr 2011 17:28:27 +0000 Todd 315@http://bbs.zhenghui.org/ <p>没看懂说的什么。。。 </p> http://bbs.zhenghui.org/topic/%e6%b1%82%e5%90%8e%e7%bb%ad%e9%98%85%e8%af%bb%e6%8e%a8%e8%8d%90#post-314 Sun, 24 Apr 2011 21:19:43 +0000 awayings 314@http://bbs.zhenghui.org/ <p>谢谢您的回复。是我弄错了，我看的是第一版的。 </p> http://bbs.zhenghui.org/topic/%e6%b1%82%e5%90%8e%e7%bb%ad%e9%98%85%e8%af%bb%e6%8e%a8%e8%8d%90#post-313 Sun, 24 Apr 2011 18:53:21 +0000 hui 313@http://bbs.zhenghui.org/ <p>P400的插语2没有问题，请注意文献【2】中的Effective Java是第二版的，item 2是</p> <blockquote><p>Consider a builder when faced with many constructor parameters </p></blockquote> <p>关于讲述比较具体的设计模式的书，除GoF外，《Head First Design Patterns》也很有名，只是过于简单。其他可参见：Martin Fowler的《Patterns of Enterprise Application Architecture》及《Refactoring: Improving The Design Of Existing Code》，Bruce Eckel的《Thinking in Patterns： Problem-Solving Techniques using Java》，Mark Grand的《Patterns in Java》第一卷。如果有时间，可参阅五卷本的《Pattern-Oriented Software Architecture》，当然其中的模式不限于设计模式，还包括架构模式。 </p> http://bbs.zhenghui.org/topic/%e5%8f%98%e9%87%8f%e4%b8%8e%e5%87%bd%e6%95%b0lazy-eager#post-312 Sun, 24 Apr 2011 18:25:36 +0000 hui 312@http://bbs.zhenghui.org/ <p>有趣的想法。另外，可以考虑把你的讲座内容拿出来与人分享。 </p> http://bbs.zhenghui.org/topic/%e6%b1%82%e5%90%8e%e7%bb%ad%e9%98%85%e8%af%bb%e6%8e%a8%e8%8d%90#post-311 Sun, 24 Apr 2011 01:05:50 +0000 awayings 311@http://bbs.zhenghui.org/ <p>非常幸运能读到这本书，让我从一个编程的门外汉得以窥见通向这个领域的种种大道和它们生动的细节。唯有遗憾之处在于很多地方未能展开以详情。前面讲编程范式只是告诉我们世界上有刀枪有各种武功门派，中间讲对象导向算是讲了一家的内功心法，最后走马观花般的浏览了下招式。 求问如果想细读对象导向的设计模式，有哪些阅读可以推荐。书中讲设计模式的参考阅读只有一本经典的设计模式一书，有无其他细节实例的书籍？网上搜到讲这些的文章不少，很多拼凑的例子实在是让人难以下咽。本人素来太懒的关系。</p> <p>另外P400的插语似乎有误，解释创建者模式有助于解决构造函数参数过长的问题。说“可参见文献【2】item2”。翻开文献【2】Effective Java：<br /> item 2，Enforce the singleton property with a private constructor，似乎没有多大关系<br /> item 1, Consider providing static factory methods instead of constructors，似乎是静态工厂的。总算是靠点边。 </p> http://bbs.zhenghui.org/topic/%e5%8f%98%e9%87%8f%e4%b8%8e%e5%87%bd%e6%95%b0lazy-eager#post-310 Sat, 23 Apr 2011 16:32:14 +0000 Lumj 310@http://bbs.zhenghui.org/ <p>冒号老师,我最近从FP中又悟出些奇妙的道理:<br /> http://tieba.baidu.com/f?kz=1059256883<br /> PS:上周我在学校的微软俱乐部尝试以abstraction为主题进行了一个小讲座,非常酣畅! </p> http://bbs.zhenghui.org/topic/%e7%b2%be%e7%a5%9e%e5%92%8c%e6%80%9d%e6%83%b3#post-309 Tue, 05 Apr 2011 20:12:11 +0000 hui 309@http://bbs.zhenghui.org/ <p>我以前看的书太杂，也谈不上系统，实在难以列出书单。写〈冒号课堂〉时提到的部分，均是随兴而写，未刻意而为。倒是写系列博文《论思维的刚性与柔性》时系统地参考了一些书籍，有空完成其中的《科学的迷信》后，会列出一份参考书目。 </p>