http://bbs.zhenghui.org/tags/class 冒号论坛 » Tag: class - Recent Posts en-US Wed, 08 Feb 2012 23:01:35 +0000 http://bbpress.org/?v=1.0.2 q http://bbs.zhenghui.org/search.php http://bbs.zhenghui.org/topic/%e4%b8%8d%e7%9f%a5%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%af%b9public-static-void-main%e7%8e%b0%e8%b1%a1%e6%80%8e%e4%b9%88%e7%9c%8b#post-266 Thu, 23 Dec 2010 18:01:19 +0000 Lumj 266@http://bbs.zhenghui.org/ <p>接上面——即使这时一个可执行程序(而不是dll模块)的代码的语义成为了声明式的 </p> http://bbs.zhenghui.org/topic/%e4%b8%8d%e7%9f%a5%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%af%b9public-static-void-main%e7%8e%b0%e8%b1%a1%e6%80%8e%e4%b9%88%e7%9c%8b#post-265 Thu, 23 Dec 2010 17:59:03 +0000 Lumj 265@http://bbs.zhenghui.org/ <p>其实,如果这样设计,我便觉得完全可以接受:<br /> 一个可执行程序需要实现一个Program class,完成其中的start方法以作为程序的入口点——这类似j2me中的MIDlet<br /> 因为这时这个class的意义明确,启动程序被看作实例化一个代表这个程序的对象,没有任何思维上的生造 </p> http://bbs.zhenghui.org/topic/%e4%b8%8d%e7%9f%a5%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%af%b9public-static-void-main%e7%8e%b0%e8%b1%a1%e6%80%8e%e4%b9%88%e7%9c%8b#post-263 Sat, 18 Dec 2010 11:58:23 +0000 Lumj 263@http://bbs.zhenghui.org/ <p>哦..嗯,我也不赞同,我觉得很奇怪<br /> 嗯,我知道,我正是说对于java或c#这样的非声明式的语言来说,动作性是不可能改变的本质<br /> 我觉得纯过程式的程序的运行是建立状态然后控制它以可以完成问题逻辑的方式不断地进行状态的切换,对象式的程序首先本质上与它无异,然后它另提供了把问题中凸显出的具有明显特征的"状态-过程"组抽出并敛起的工具.仅此罢了.但由此人可以把具有密切关联的"状态-过程"组凝聚成簇,然后把它作为一个状态管理单位来管理,就好像在有些google maps应用中当Marker太多时会凝聚成簇的那种感觉一样,而周围仍然有散落的小Marker.所以我觉得如果我们站在一个object的方法内部,我们应该无法判断自己是在一个object的方法内部的流程中还是在所谓的"全局"流程中.强迫把每个函数都装进class实在很没有道理 </p> http://bbs.zhenghui.org/topic/%e4%b8%8d%e7%9f%a5%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%af%b9public-static-void-main%e7%8e%b0%e8%b1%a1%e6%80%8e%e4%b9%88%e7%9c%8b#post-262 Sat, 18 Dec 2010 00:44:13 +0000 hui 262@http://bbs.zhenghui.org/ <blockquote><p>C++中“臭名昭著”的过程式与对象式的混用 </p></blockquote> <p>我特意在“臭名昭著”四个字上加上引号，便表示本人并不赞同这个说法。“过程”与“对象”当然不是互斥的，在《冒号课堂》中关于编程范式的分类中对此已作过说明。对于Java、C#等语言来说，整体设计采用的对象式思维，具体实现对象的每个方法则是过程式思维。至于你提到程序的动作性，这个也不是绝对的。比如prolog是纯声明式语言（更具体地，是逻辑式语言），不需要对"要做些什么"进行描述，只需要罗列一些规则、事实和目标即可，具体的程序执行动作由解释器自动完成。 </p> http://bbs.zhenghui.org/topic/%e4%b8%8d%e7%9f%a5%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%af%b9public-static-void-main%e7%8e%b0%e8%b1%a1%e6%80%8e%e4%b9%88%e7%9c%8b#post-261 Sat, 18 Dec 2010 00:01:32 +0000 Lumj 261@http://bbs.zhenghui.org/ <p>最后一行打错了,是"两个词语" </p> http://bbs.zhenghui.org/topic/%e4%b8%8d%e7%9f%a5%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%af%b9public-static-void-main%e7%8e%b0%e8%b1%a1%e6%80%8e%e4%b9%88%e7%9c%8b#post-260 Sat, 18 Dec 2010 00:00:44 +0000 Lumj 260@http://bbs.zhenghui.org/ <p>嗯,不过static import只使得引用函数时不需要全名,而这一定程度上可以说使得事情变得更加难以理解;c# static class更是对缓解代码冗余毫无帮助(初识c# static class时我还期望它能以一个static省去class内的所有static,后来发现原来仍然不能省略,这static只是作检查确保所有成员皆static(嗯,这点还算是积极的)),而且根本上这个class仍以一种十分不可理解的身份出现,一点也没有变好<br /> "hype",呵呵,我感觉这是不小的遗憾啊!<br /> 哦,对了,你提到<br /> C++中“臭名昭著”的过程式与对象式的混用<br /> 呃..其实每次看到这样的陈述我都很迷惑,我会想,事情不就该是这样的吗?"过程"与"对象"为什么会被认为是互斥的???冒号老师能说说么?<br /> 我想程序本就是对"要做些什么"的描述,本是动作性的,而OOP语言帮助人把脑中的概念映射为代码中的class,使得可以以一种相当直接的方式来表达,并自然形成局部的"对象性"的(相对于动作性)静态的具有声明语义(相对于动作流语义)的.."东西"(不想用"对象"这个词,怕混了),但这又怎能影响程序的动作性这一全局本质呢?不可能因为这一点,程序本身就成为对某个"东西"进行声明了<br /> 呃..先说这些吧,我怕没说到点子上或者我对那再修词语的理解有问题,期待老师阐释一下! </p> http://bbs.zhenghui.org/topic/%e4%b8%8d%e7%9f%a5%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%af%b9public-static-void-main%e7%8e%b0%e8%b1%a1%e6%80%8e%e4%b9%88%e7%9c%8b#post-259 Fri, 17 Dec 2010 23:21:44 +0000 hui 259@http://bbs.zhenghui.org/ <p>Java后来引进了static import，C#也增加了static class，在一定程度上缓解了代码冗余。至于当初为何如此设计，恐怕是为了强调“一切都是对象”，以有别于C++中“臭名昭著”的过程式与对象式的混用。这里面恐怕不全出于技术方面的原因，也是一种宣传的噱头，故此不少人认为OOP是一种hype。 </p> http://bbs.zhenghui.org/topic/%e4%b8%8d%e7%9f%a5%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%af%b9public-static-void-main%e7%8e%b0%e8%b1%a1%e6%80%8e%e4%b9%88%e7%9c%8b#post-258 Fri, 17 Dec 2010 23:05:23 +0000 Lumj 258@http://bbs.zhenghui.org/ <p>嗯,对的,我记得你提过的这段话,很有印象<br /> 一些使用者"习惯了"?嗯..我怎么感觉这个设计带来的麻烦真的不少啊,不仅是冗余了<br /> 在Utility class之类的static class中,放一些函数,每个加上static修饰,此为"冗余",然后调用时的代码的外观确是不冗余(Utility.SomeMethod()),但它毕竟是class,强人所难,如果在Utility里有需要作进一步划分,比如,Math.Calculas,Math.Geometry,那继续拿着这个class就吃力了(内嵌的static class?),如果放弃的话,那些函数就只能在同一层级上.这岂不就不只是代码简不简洁的问题了?它影响到设计了啊<br /> 根本上,class本就不是希望让人这样使用的吧,岂不是得了锤子,一切都成了钉子?<br /> 我与身边的人讨论这个问题的时候,理由大抵是"为了模块化","这是OOP","为了避免名字冲突"这3个<br /> 然后我就说,"OOP?这和OOP一点边都搭不上,'O',object,敢问这个Math里哪有object?" </p> http://bbs.zhenghui.org/topic/%e4%b8%8d%e7%9f%a5%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%af%b9public-static-void-main%e7%8e%b0%e8%b1%a1%e6%80%8e%e4%b9%88%e7%9c%8b#post-257 Fri, 17 Dec 2010 21:42:19 +0000 hui 257@http://bbs.zhenghui.org/ <p>这个问题在《冒号课堂》曾经提过，以下引自6.1章节中的一段话——</p> <blockquote><p> OOP又不是金子，含量越高越好。试图把一切都装进OOP的箱子里的想法无异于削足适履。典型的如Java中的Math类，逻辑上压根儿就不存在什么Math对象，清一色的static方法和常量就是最好的讽刺。在C++中只要在math的namespace中定义一些自由函数就可以了，自然而简洁。</p></blockquote> <p>对此设计表示不满的人肯定是有的，只是Java更多地用来写较大型程序，使用者大多习惯了java的一些冗余设计。在OOP语言中，除了C++、python、ruby等以外，Java的脚本版（粗略这么说吧）Groovy语言也是允许自由函数的存在的。毕竟，人们还是更喜欢简洁而自然的代码的。 </p> http://bbs.zhenghui.org/topic/%e4%b8%8d%e7%9f%a5%e5%86%92%e5%8f%b7%e8%80%81%e5%b8%88%e5%af%b9public-static-void-main%e7%8e%b0%e8%b1%a1%e6%80%8e%e4%b9%88%e7%9c%8b#post-255 Fri, 17 Dec 2010 20:13:24 +0000 Lumj 255@http://bbs.zhenghui.org/ <p>冒号老师,我快把你的书看完了,在最后一章,哈哈,对书里对抽象的讨论非常喜欢<br /> 第一次在这发帖,想听听在一些我感兴趣的问题上你是怎么看的<br /> Java,c#都不允许全局函数,从而程序的入口点也必须成为某class的static方法,这一点上我好像还没听到哪位身边的朋友对其持批评态度的.不知你是怎么看的?<br /> 我的观点呢..其实很激烈,我认为这个设计很愚蠢.我想先不列出我认为这样的设计不合理的理由,先听听你是怎么看的?<br /> 我就先说一个很直白的理由吧:<br /> 我记得我第一次写下这个class时在给它起什么名上翻覆良久,最后实在无法,就随便拿了个名字来,好赶快写下面的<br /> 而给它起名如此痛苦,并非一种描述无能,而是,我根本不知道它是什么!我想我的脑中根本就没有这样一个"class"!<br /> 程序设计这项活动的本质便是把问题空间(逻辑空间)至代码空间作一个映射,而这个class我却在问题空间中完全找不到,它存在的意义是什么?<br /> 无法给它作身份定位.如果给变量起名,我知道,它维持程序的状态,也往往映射到逻辑空间中的某个对象;给class起名,我知道,它是逻辑空间中的概念在代码中的对应体;给namespace起名,我知道,它象征了论域,语境.而对这个天上掉下来的class,我实在无法想象它是以什么身份出现在我这的<br /> 嗯,先说这些,冒号老师你怎么看?<br /> 呃,再多说一句,我至今很奇怪,我几乎没有听闻在这个设计上有引起争议?(也可能是我的信息范围比较小吧,呵呵) </p> 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/ <p>&gt;&gt;比如成员方法是某种算法的名称。我想你关心的应该是这种情况吧？</p> <p>正是这种情况，谢谢！ </p> 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/ <p>&gt;&gt;1.STL中的算法多是作为函数提供的，没有作为容器类的成员方法。</p> <p>在STL中，有意将算法与容器分离，让iterator作为它们之间的桥梁。这可令算法不受容器的限制，从而尽可能地普适。至于说到没有达到高内聚的效果，那是不可避免的，在一定层次上的（关注点分离带来的）解耦与（数据与运算粘合带来的）内聚本来就是一对矛盾。</p> <p>&gt;&gt;2.对于存在交互情况，比如：画笔在画纸上作画，我觉得不管是paper.draw(pen)还是pen.draw(paper)都不如用函数表达为draw(paper,pen)来得自然。</p> <p>这个问题在书中p429也曾简单提到过。如果是两个或两个以上的对象<strong>平等</strong>合作地完成一项任务，无论谁作为主体对象都不是很合适。引入一个中间的服务对象是一种方法，另外，由于C++支持自由函数，直接用无对象（但最好有namespace）的函数也不失为一种选择。</p> <p>&gt;&gt;请问有没有一个比较好的方法来分析算法什么情况下适合设计为类的成员方法呢？什么情况下又应该作为独立的函数(C++)或者是抽象为服务呢？</p> <p>你的帖子的题目是“成员方法的疑问”。如果单从设计的角度说，成员方法通常与算法不是一个层面的概念。因为从数据抽象的观点来看，成员方法的API规范中通常是不涉及具体算法的，即只说明what to do，不涉及how to do。当然也有例外，比如成员方法是某种算法的名称。我想你关心的应该是这种情况吧？对于这种情况，我的看法如下：<br /> 1、如果把算法绑定到某个类会影响算法的普适性，则用独立函数比较合适；<br /> 2、如果算法涉及到两个以上的没有明显主次之分的类，则用独立函数或中间服务类比较合适；<br /> 3、其他情况，建议设计为类的成员方法。尤其是如果算法有side-effect，或者需要多个步骤（如各种加密文件的算法），用对象来储存不同的状态比较方便，还能在一定程度上保证调用的次序（比如采用一些辅助的私有变量）。 </p> 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/ <p>OOP是以数据为中心组织算法的。OOP把面向过程的函数变成了类的成员方法的过程，也是过程抽象到数据抽象的转变过程。但我发现，即使在OOP中过程抽象似乎还有存在的意义，特别是，我常对成员方法的设计还是有感觉拿不准的地方。比如：</p> <p>1.STL中的算法多是作为函数提供的，没有作为容器类的成员方法。对于这个问题，我觉得STL的设计有它的合理的一面：因为sort，transform等算法本身也是一种被人所熟知的概念，它的独立存在是对概念的直接表达；独立性也增强了算法的普适性。但这样的设计也有缺点：对象的行为不够饱满；用户不仅需要获取对象，还需要依赖额外的算法，没有达到数据抽象的高内聚效果。了解mixin以后，我觉得也许mixin是解决这个问题的更好方法：既保持算法的独立性；又可以方便地混入对象达到数据对算法的吸附作用。</p> <p>2.对于存在交互情况，比如：画笔在画纸上作画，我觉得不管是paper.draw(pen)还是pen.draw(paper)都不如用函数表达为draw(paper,pen)来得自然。据我所知，这种情况在建模中常抽象为一种服务来表达某一功能，比如：DrawService。</p> <p>请问有没有一个比较好的方法来分析算法什么情况下适合设计为类的成员方法呢？什么情况下又应该作为独立的函数(C++)或者是抽象为服务呢？ </p>