冒号论坛 » Tag: OOP

冒号论坛 » Tag: OOP - Recent Posts http://bbs.zhenghui.org/tags/oop 冒号论坛 » Tag: OOP - Recent Posts en-US Wed, 08 Sep 2010 12:37:14 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://bbs.zhenghui.org/search.php 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)（可参见 <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最终目的是为了降低软件的脆弱性、增强软件的可维护性。 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是半成品。 hui on "subtype和subclass" 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/ 非常好的文章，多谢分享。其中谈到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。即：子类用于类的内部重用，子类型用于外部重用。这个与《冒号课堂》中提到的观点本质上是一致的：实现继承消费可重用的旧代码，接口继承生产可重用的新代码；接口继承不是为了代码重用，而是为了代码被重用。 另：该文章的PDF版可到 <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.9.7539&rep=rep1&type=pdf" rel="nofollow">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.9.7539&rep=rep1&type=pdf</a> 下载。 Todd on "subtype和subclass" http://bbs.zhenghui.org/topic/subtype%e5%92%8csubclass#post-130 Mon, 14 Jun 2010 00:13:36 +0000 Todd 130@http://bbs.zhenghui.org/ 虽然subtype和subclass是OOP中最基本的问题之一，但我是在读《冒号课堂》的时候才开始注意到这个问题。我想国内的程序员不能区分subtype和subclass的不在少数。下面这个资料对于subtype和subclass讨论得比较深入，贴上来分享： <a href="http://www.cs.princeton.edu/courses/archive/fall98/cs441/mainus/mainus.html" rel="nofollow">http://www.cs.princeton.edu/courses/archive/fall98/cs441/mainus/mainus.html</a> 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都能发现出这么深刻的道理！ <a href="http://en.wikipedia.org/wiki/Church_numeral" rel="nofollow">http://en.wikipedia.org/wiki/Church_numeral</a> 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（没有封装机制），但还是能从概念上支持的。 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-88 Fri, 19 Mar 2010 12:24:15 +0000 Todd 88@http://bbs.zhenghui.org/ 谢谢！可不可以这样理解《冒号课堂》中的C语言实现队列的例子：虽然还是C语言的一组函数，但它的目的已经不是过程抽象，而是数据抽象。OOP让数据抽象变得更自然。 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-87 Fri, 19 Mar 2010 12:02:54 +0000 hui 87@http://bbs.zhenghui.org/ >>OOP的数据抽象正是以数据为中心组织操作 这个说法稍微有点问题。既然上面提到的“数据”是用“操作”来定义的，那么“以数据来组织操作”便有循环定义之嫌了。《冒号课堂》中的提法是：OOP是“以数据为中心组织逻辑”(P39)。 这么说可能更清楚些：在OOP中，定义数据抽象是类的设计者的任务，选择数据结构(data structure)并以之为中心实现各接口是类的实现者的任务。（在实际编程中，这二者的角色可能一人承担） 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-86 Fri, 19 Mar 2010 11:29:12 +0000 hui 86@http://bbs.zhenghui.org/ >>数据本身只是一个符号，它的特征是由其相关的一系列操作（包括构造和使用两类）所体现的 这种理解是正确的。之所以说数据是抽象的，是因为我们不关心其内部的具体结构表示（representation），只关心它是如何被创建、如何被使用的。也就是说，数据应当被当作一个黑箱来使用，任何超过其定义的使用方式都是侵犯其隐私、破坏其抽象的行为。 不过，上述“符号”二字或许改为“对象”（广义的对象，并非OOP中狭义的对象）更贴切些，因为前者容易让人把数据与指代它的变量混为一谈。事实上，在你参考的文章中也是使用“data object”的字眼。 如果以这种方式来理解数据，那么就很容易理解“函数也是数据”的思想了。在SICP中讲述的Scheme语言正体现了这种函数式风格。 在此基础上，（抽象）数据类型的概念也非常自然了。ADT关心的是通过接口定义在一类数据上的行为，而不是它们的内部数据结构。 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-85 Fri, 19 Mar 2010 10:22:32 +0000 Todd 85@http://bbs.zhenghui.org/ 今天看了SCIP的数据抽象一节，然后结合之前《冒号课堂》的内容，我感觉对数据的认识又深入了一些。 我现在对数据的认识是：数据在程序中是一个符号和该符号上的操作规则。比如：定义了一个符号pair，若pair = make_pair(x, y)则left(pair) == x, right(pair) == y。pair本身只是一个符号，它的特征是由其相关的一系列操作（包括构造和使用两类）所体现的。OOP的数据抽象正是以数据为中心组织操作。不知道理解对不对？ 参考文章： <a href="http://mitpress.mit.edu/sicp/full-text/sicp/book/node30.html" rel="nofollow">http://mitpress.mit.edu/sicp/full-text/sicp/book/node30.html</a> Todd on "成员方法的疑问" http://bbs.zhenghui.org/topic/%e6%88%90%e5%91%98%e6%96%b9%e6%b3%95%e7%9a%84%e7%96%91%e9%97%ae#post-75 Thu, 04 Mar 2010 10:09:56 +0000 Todd 75@http://bbs.zhenghui.org/ >>比如成员方法是某种算法的名称。我想你关心的应该是这种情况吧？ 正是这种情况，谢谢！ hui on "成员方法的疑问" http://bbs.zhenghui.org/topic/%e6%88%90%e5%91%98%e6%96%b9%e6%b3%95%e7%9a%84%e7%96%91%e9%97%ae#post-74 Tue, 02 Mar 2010 23:14:47 +0000 hui 74@http://bbs.zhenghui.org/ >>1.STL中的算法多是作为函数提供的，没有作为容器类的成员方法。 在STL中，有意将算法与容器分离，让iterator作为它们之间的桥梁。这可令算法不受容器的限制，从而尽可能地普适。至于说到没有达到高内聚的效果，那是不可避免的，在一定层次上的（关注点分离带来的）解耦与（数据与运算粘合带来的）内聚本来就是一对矛盾。 >>2.对于存在交互情况，比如：画笔在画纸上作画，我觉得不管是paper.draw(pen)还是pen.draw(paper)都不如用函数表达为draw(paper,pen)来得自然。 这个问题在书中p429也曾简单提到过。如果是两个或两个以上的对象平等合作地完成一项任务，无论谁作为主体对象都不是很合适。引入一个中间的服务对象是一种方法，另外，由于C++支持自由函数，直接用无对象（但最好有namespace）的函数也不失为一种选择。 >>请问有没有一个比较好的方法来分析算法什么情况下适合设计为类的成员方法呢？什么情况下又应该作为独立的函数(C++)或者是抽象为服务呢？ 你的帖子的题目是“成员方法的疑问”。如果单从设计的角度说，成员方法通常与算法不是一个层面的概念。因为从数据抽象的观点来看，成员方法的API规范中通常是不涉及具体算法的，即只说明what to do，不涉及how to do。当然也有例外，比如成员方法是某种算法的名称。我想你关心的应该是这种情况吧？对于这种情况，我的看法如下： 1、如果把算法绑定到某个类会影响算法的普适性，则用独立函数比较合适； 2、如果算法涉及到两个以上的没有明显主次之分的类，则用独立函数或中间服务类比较合适； 3、其他情况，建议设计为类的成员方法。尤其是如果算法有side-effect，或者需要多个步骤（如各种加密文件的算法），用对象来储存不同的状态比较方便，还能在一定程度上保证调用的次序（比如采用一些辅助的私有变量）。 Todd on "成员方法的疑问" http://bbs.zhenghui.org/topic/%e6%88%90%e5%91%98%e6%96%b9%e6%b3%95%e7%9a%84%e7%96%91%e9%97%ae#post-73 Tue, 02 Mar 2010 22:09:24 +0000 Todd 73@http://bbs.zhenghui.org/ OOP是以数据为中心组织算法的。OOP把面向过程的函数变成了类的成员方法的过程，也是过程抽象到数据抽象的转变过程。但我发现，即使在OOP中过程抽象似乎还有存在的意义，特别是，我常对成员方法的设计还是有感觉拿不准的地方。比如： 1.STL中的算法多是作为函数提供的，没有作为容器类的成员方法。对于这个问题，我觉得STL的设计有它的合理的一面：因为sort，transform等算法本身也是一种被人所熟知的概念，它的独立存在是对概念的直接表达；独立性也增强了算法的普适性。但这样的设计也有缺点：对象的行为不够饱满；用户不仅需要获取对象，还需要依赖额外的算法，没有达到数据抽象的高内聚效果。了解mixin以后，我觉得也许mixin是解决这个问题的更好方法：既保持算法的独立性；又可以方便地混入对象达到数据对算法的吸附作用。 2.对于存在交互情况，比如：画笔在画纸上作画，我觉得不管是paper.draw(pen)还是pen.draw(paper)都不如用函数表达为draw(paper,pen)来得自然。据我所知，这种情况在建模中常抽象为一种服务来表达某一功能，比如：DrawService。 请问有没有一个比较好的方法来分析算法什么情况下适合设计为类的成员方法呢？什么情况下又应该作为独立的函数(C++)或者是抽象为服务呢？