冒号论坛 » Tag: OOP

冒号论坛 » Tag: OOP - Recent Posts http://bbs.zhenghui.org/tags/oop 冒号论坛 » Tag: OOP - Recent Posts en-US Wed, 08 Feb 2012 22:48:21 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://bbs.zhenghui.org/search.php hui on "对象的消息模型" 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/ 嗯，这个解释应当是比较直观和容易理解的。动态类型语言之“动态”所在，是类型之动态，因此在运行前检查类型毫无意义；动态语言之“动态”，是语言之动态，因此对象/类的方法、属性等是可能在运行期间改变的。你提到的这篇文章解释了一件事情：对于一个静态类型的动态语言（如scala、groovy），虽然在运行前应当检查类型但有时并非如此，原因是：其动态语言的特征决定了有些method call的dispatch在运行前并不确定，因此无法检查参数类型。 Todd on "对象的消息模型" 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/ 关于动态语言与动态类型语言的区别，今天看了这篇文章才稍微明白一点：<a href='http://groovy.dzone.com/news/dynamic-typing-vs-dynamic-lang' rel="nofollow">Dynamic Typing vs Dynamic Language Explained</a>。我理解动态类型语言是指同一个名称可以动态绑定到不同类型的对象上，比如： a = 1; a = 'test'； 而动态语言可能是非动态类型的，比如a只能绑定到一种对象类型，但是可以动态添加删除修改方法和属性，方法的调用是动态分派的： A a = new A(); a.f = function() { ... } a.f() 不知道理解是否正确？ Todd on "对象的消息模型" 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/ 应该是书上介绍过，但我没有留下什么印象，一直没有加以区别。 hui on "对象的消息模型" 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/ 看来是《冒号课堂》中的叙述还不够清晰？动/静态类型语言的区别在于类型检查的时间：前者在编译期（或运行之前），后者在运行期。动/静态语言的区别是：前者的代码行为可能在运行时改变（比如类的方法、属性的增减或修改），后者则不可能。 Todd on "对象的消息模型" 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/ 其实，我对“静/动态语言”和“静/动态类型语言”的区别不是很清楚。郑老师认为二者的区别是什么呢？ hui on "对象的消息模型" 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/ 文章写得挺好的，抓住了消息模型的特征。有一个小问题，你在文章和此处一再提到“静态类型语言”与“动态类型语言”的差别，但其实这更多的是“静态语言”与“动态语言”的差别。正是因为动态语言有可能在运行时改变对象的方法，才使得诸如“Method Missing"的特征熠熠生辉。 Todd on "对象的消息模型" 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/ 以前我主要接触的静态类型语言，现在接触了动态语言之后对于对象的消息模型又有了一些新的理解。今天把理解写出了出来，请郑老师看看，谢谢！http://www.cnblogs.com/weidagang2046/archive/2011/08/14/2138059.html Lumj on "迪米特法则" http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-296 Fri, 21 Jan 2011 11:16:33 +0000 Lumj 296@http://bbs.zhenghui.org/ 对的 Todd on "迪米特法则" http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-295 Tue, 18 Jan 2011 13:33:25 +0000 Todd 295@http://bbs.zhenghui.org/ >>一个对象尽量不要与不在同一抽象层次的另一对象打交道。 我认为C和C++的指针之所以危险，一个重要原因就是它同时具备了两个抽象层次，一是底层的内存地址；一是高层的对象引用。 Lumj on "迪米特法则" http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-294 Sat, 15 Jan 2011 18:52:46 +0000 Lumj 294@http://bbs.zhenghui.org/ 呃..原来我还搞错了一个词.. 每次都是扫到这个词的,我迅雷不及掩耳地就以为那个词是intend变来的一个形容词,觉得这个词相当传神呢.. hui on "迪米特法则" http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-293 Sat, 15 Jan 2011 17:50:11 +0000 hui 293@http://bbs.zhenghui.org/ PIE原则是“program intently and expressively”，intently与intensively不是一回事。你的说法虽然有些模糊，但还是抓住了一个要点，即：LoD涉及抽象层次问题（语义与抽象密切相关），一个对象尽量不要与不在同一抽象层次的另一对象打交道。比如，此处人（作为狗的命令者）与狗处于同一层次，但狗的腿则处于更下一层。人应当与狗打交道，而不是它的腿。 Lumj on "迪米特法则" http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-292 Sat, 15 Jan 2011 17:24:51 +0000 Lumj 292@http://bbs.zhenghui.org/ 最近对这个法则又有了更多的体会 LoD是PIE(Program intensively and expressively)原则的一种很直接的体现 intensively,and expressively,其实即是不要降级语义 要做什么事,就让对象对这种情况知情和付诸关注,而不要自己在对象外实现掉一层(更有甚者是若干层)高层语义,再把剩下的转发给对象 隐晦和拐弯抹角即意味着不受支持,不会在发生变化时被对象纳入考虑,从而脱节 象dog.legs.run()的情况即是:这条狗并不懂得run,是外界隐晦地告诉它的,"dog会run"这层语义即是名存实亡的,是Dog外部的一厢情愿 Lumj on "迪米特法则" http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-291 Wed, 12 Jan 2011 21:43:05 +0000 Lumj 291@http://bbs.zhenghui.org/ "tell代表一个抽象的命令，而ask代表（被命令对象的）具体执行方法或步骤" 嗯,这样的话便容易理解了,我知道了 我本来的理解是一种荒唐的理解: <code> if(nameTextBox.getText()=="Lumj"){//ask,decide alert("This is our admin's name,you cannot use it"); nameTextBox.setText(String.empty);//tell } </code> hui on "迪米特法则" http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-290 Wed, 12 Jan 2011 19:46:36 +0000 hui 290@http://bbs.zhenghui.org/ 用Number作例子是不恰当的，如果这个Number是基本类型的话。相反，如果Number包含足够的业务逻辑，那么magic number的处理正应该是Number的职责。 一个通俗的tell, don't ask的例子是：要一只狗跑，不是dog.getLegs().run()，而是dog.run()，即不是指挥狗的腿来跑，而是由狗自己负责调用腿来跑。事实上，指挥者根本不在乎狗有没有腿，只在乎它能不能跑。至于它用腿跑，还是聪明到能用嘴控制某个机动车来跑，则是狗的职责，不是指挥者的职责。因此“tell, don't ask”是一种良好的职责分工原则，能使代码保持合理的抽象层次划分。 可以这么理解：tell代表一个抽象的命令，而ask代表（被命令对象的）具体执行方法或步骤。 Lumj on "迪米特法则" http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-289 Wed, 12 Jan 2011 16:29:14 +0000 Lumj 289@http://bbs.zhenghui.org/ 我很难理解tell,don't ask这个原则 我看了在2L给出的文章, That is, you should endeavor to tell objects what you want them to do; do not ask them questions about their state, make a decision, and then tell them what to do 使外界能了解自己的状态不正是对象的职责吗?不知这个理解哪里有误? 不过我猜想是否这样: 首先,ask没问题,可是不该以ask的结果为依据对其tell 然后,"ask,decide,then tell"针对的是对象职责范围内的逻辑 我想到个例子: if(someControl.isVisible()) someControl.hide(); 就是对象的职责外泄,因为"在已经隐藏的情况下无须调用hide"是Control自然该管的,正确的做法是: someControl.hideIfVisible(); 而同样是"ask,decide,then tell",却不可能将 if(someNumber.isLargerThan(100)) someNumber=100; 敛为Number.truncateIfLargerThanOneHundred供人调用,因为100这个数字在只谈论Number的时候是个magic number,它的语义是在Number以外才得以实现的 Lumj on "实现继承问题的经典实例" http://bbs.zhenghui.org/topic/%e5%ae%9e%e7%8e%b0%e7%bb%a7%e6%89%bf%e9%97%ae%e9%a2%98%e7%9a%84%e7%bb%8f%e5%85%b8%e5%ae%9e%e4%be%8b#post-285 Mon, 10 Jan 2011 23:48:01 +0000 Lumj 285@http://bbs.zhenghui.org/ 嗯.. hui on "实现继承问题的经典实例" http://bbs.zhenghui.org/topic/%e5%ae%9e%e7%8e%b0%e7%bb%a7%e6%89%bf%e9%97%ae%e9%a2%98%e7%9a%84%e7%bb%8f%e5%85%b8%e5%ae%9e%e4%be%8b#post-283 Mon, 10 Jan 2011 23:26:17 +0000 hui 283@http://bbs.zhenghui.org/ 以上提到了实现继承的三种常见pitfall：继承（或实现）一个父类方法时可能会影响另外的超类方法；实现某些接口时可能对非public方法有特殊要求；子类在覆盖父类方法时可能需要调用某些特别的方法（最常见的是父类的被覆盖方法）。此外还有其他可能，比如《冒号课堂》p269提到的某些方法的实现细节不得不出现在规范文档中，容易被人忽略；再比如，有些子类并未实现某接口的全部方法，如有些Java类的方法只是简单地throw UnsupportedOperationException（严格说来这是不满足里氏代换原则的）。 Lumj on "实现继承问题的经典实例" http://bbs.zhenghui.org/topic/%e5%ae%9e%e7%8e%b0%e7%bb%a7%e6%89%bf%e9%97%ae%e9%a2%98%e7%9a%84%e7%bb%8f%e5%85%b8%e5%ae%9e%e4%be%8b#post-281 Mon, 10 Jan 2011 22:58:49 +0000 Lumj 281@http://bbs.zhenghui.org/ 最近在使用js独自开发一个HTML UI库的时候,才开始有感于实现继承对于子类提出的潜要求的普遍存在性 工程规模还不十分大,所见到的最常见的"潜要求"就是,子类实现某方法时必须在开头或结尾调用基类的某方法 两位提到的情形我能想象,只是没见过,不知在现实中我上面所说的这类潜要求和两位提到的潜要求是否占了这类潜要求的一大块份额? hui on "实现继承问题的经典实例" http://bbs.zhenghui.org/topic/%e5%ae%9e%e7%8e%b0%e7%bb%a7%e6%89%bf%e9%97%ae%e9%a2%98%e7%9a%84%e7%bb%8f%e5%85%b8%e5%ae%9e%e4%be%8b#post-275 Mon, 03 Jan 2011 20:02:27 +0000 hui 275@http://bbs.zhenghui.org/ 是的。大部分类的接口规范是独立的，但也有一些接口是互相关联的，你提到的equals与hashCode就是一例。此外，有些接口的实现不仅对public方法有要求，还可能对private方法有要求。比如Java中一个类如果是Serializable类型，并且希望定制序列化过程，则需要实现私有的writeObject和readObject方法。 Todd on "实现继承问题的经典实例" http://bbs.zhenghui.org/topic/%e5%ae%9e%e7%8e%b0%e7%bb%a7%e6%89%bf%e9%97%ae%e9%a2%98%e7%9a%84%e7%bb%8f%e5%85%b8%e5%ae%9e%e4%be%8b#post-274 Mon, 03 Jan 2011 16:46:05 +0000 Todd 274@http://bbs.zhenghui.org/ "You must override hashCode() in every class that overrides equals(). Failure to do so will result in a violation of the general contract for Object.hashCode(), which will prevent your class from functioning properly in conjunction with all hash-based collections, including HashMap, HashSet, and Hashtable." -- from Effective Java, by Joshua Bloch 《冒号课堂》中提到了实现继承的诸多问题，必须引起重视，解决的方法其中之一便是将这类实现相关的“潜规则”明确写入文档。我觉得最经典的实例就是Java中覆盖equals()方法必须同时覆盖hashCode()的问题。 hui on "迪米特法则" http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-202 Sat, 02 Oct 2010 22:55:15 +0000 hui 202@http://bbs.zhenghui.org/ 没错，现实中的模型经常是网状结构的，如何尽可能地减少非必要关联、横向或纵向分割复杂关联正是软件设计的最大挑战之一。 Todd on "迪米特法则" http://bbs.zhenghui.org/topic/%e8%bf%aa%e7%b1%b3%e7%89%b9%e6%b3%95%e5%88%99#post-201 Sat, 02 Oct 2010 11:30:03 +0000 Todd 201@http://bbs.zhenghui.org/ >>LoD虽然不是必须遵守的铁律，但一个有经验的程序员在违背它时，会听到身后的警告声：你知道得太多了：） http://www.aspiringcraftsman.com/2008/06/distilling-law-of-demeter 这篇文章讲了LoD的思想也提到了LoD不是任何场合都适用。我想到一个例子：Company与CEO的关系，CEO ceo = company.GetCEO()是违反LoD的，但这又是领域模型所需要的。 我曾经想能不能把软件设计得像汽车一样，具有清晰地功能层次和子系统边界。后来发现现实的领域模型比机械结构要复杂得多，更接近于错综复杂的网状，而不是机械的树状结构。这种追求是一种理想的情况，但不是总能达到。 hui on "Creator与Factory" http://bbs.zhenghui.org/topic/creator%e4%b8%8efactory#post-190 Wed, 15 Sep 2010 18:10:24 +0000 hui 190@http://bbs.zhenghui.org/ 在GRASP中的creator pattern中，对由谁来创建对象的问题作了说明。可参见链接： http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Creator 。另外，推荐Craig Larman的书《Applying UML and Patterns》（第三版）。 职责分配是否合理，将直接决定OO设计的成败。在《冒号课堂》第382页的关系图中，职责就是关键词之一，意识到这一点对理解OOP非常重要。 Todd on "Creator与Factory" http://bbs.zhenghui.org/topic/creator%e4%b8%8efactory#post-189 Wed, 15 Sep 2010 17:28:00 +0000 Todd 189@http://bbs.zhenghui.org/ Factory相关的模式主要是对对象创建过程的抽象，而除了创建过程还涉及到一个创建职责，即应该由谁来创建对象？这个问题似乎没有引起与Factory同等的重视。我只看到过GRASP里面提到了的Creator涉及了这方面的讨论。我准备对这一问题再进行一些深入的学习和思考。 Todd on "迪米特法则" 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/ 谢谢，推荐的文章很好，看了之后我对LoD的认识加深了不少！ 另外，还有一个意外的收获，即文中提到了CQRS。以前我觉得很多post condition/class invariant不容易在实际编程中表达，一个重要原因是assert语句不应该有副作用，现在我知道如果类的设计能采用CQRS的方式，那么就很容易写出无副作用的assert语句来表达post condition/class invariant。 另外，最近关于CQRS还看到一些持久化方面的应用，普通的持久化方案是基于对象内部状态的，而采用CQRS，把所有的commands持久化下来就得到了对象的状态以及状态历史。 hui on "迪米特法则" 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/ 迪米特法则（以下简称LoD）提倡一个类尽量不要与其间接关联的类发生直接对话。这一方面有助于减少类之间的关联，从而降低系统的耦合度；另一方面有助于界定职责范围，从而增强了系统的内聚度。从消息传递的角度看，LoD可看作一种对象交流原则：只吩咐不询问（tell, don't ask)（可参见 http://www.pragprog.com/articles/tell-dont-ask 和 http://www.c2.com/cgi/wiki?TellDontAsk ）。当然，LoD最终目的是为了降低软件的脆弱性、增强软件的可维护性。 LoD虽然不是必须遵守的铁律，但一个有经验的程序员在违背它时，会听到身后的警告声：你知道得太多了：） Todd on "迪米特法则" 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/ 目前，我能够识别并避免违背迪米特法则，但是总感觉对迪米特法则的认识深度还不够，还不能说清楚到底迪米特法则本质上意味着什么。我目前思考的结果是： OOP中，对象间的交互是消息传递模型，而消息是值语义的；而obj.GetAnotherObject()的结果是引用，违背了对象消息传递模型。所以，违背迪米特法则的设计其实是不符合OOP的。 hui on "subtype和subclass" 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/ 是的，CiteSeerx有大量高质量的学术文章。 Todd on "subtype和subclass" 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/ CiteSeer是个好地方！ Todd on "subtype和subclass" 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/ 是的，和《冒号课堂》的观点基本一致。区分了subtype和subclass就能把继承和多态的关系理清楚了。同时，对于以前不太容易区分的interface与abstract class的选择问题也会更清楚。使用interface是为了subtype，使用abstract class则包含了subtype和subclass。记得书中比喻abstract class是半成品。