日历

September 2020
M T W T F S S
 123456
78910111213
14151617181920
21222324252627
282930  

不知冒号老师对public static void Main现象怎么看?

Home Forums 《冒号课堂》讨论区 不知冒号老师对public static void Main现象怎么看?

  • This topic is empty.
Viewing 9 reply threads
  • Author
    Posts
    • #1129
      Lumj
      Member

      冒号老师,我快把你的书看完了,在最后一章,哈哈,对书里对抽象的讨论非常喜欢

      第一次在这发帖,想听听在一些我感兴趣的问题上你是怎么看的

      Java,c#都不允许全局函数,从而程序的入口点也必须成为某class的static方法,这一点上我好像还没听到哪位身边的朋友对其持批评态度的.不知你是怎么看的?

      我的观点呢..其实很激烈,我认为这个设计很愚蠢.我想先不列出我认为这样的设计不合理的理由,先听听你是怎么看的?

      我就先说一个很直白的理由吧:

      我记得我第一次写下这个class时在给它起什么名上翻覆良久,最后实在无法,就随便拿了个名字来,好赶快写下面的

      而给它起名如此痛苦,并非一种描述无能,而是,我根本不知道它是什么!我想我的脑中根本就没有这样一个”class”!

      程序设计这项活动的本质便是把问题空间(逻辑空间)至代码空间作一个映射,而这个class我却在问题空间中完全找不到,它存在的意义是什么?

      无法给它作身份定位.如果给变量起名,我知道,它维持程序的状态,也往往映射到逻辑空间中的某个对象;给class起名,我知道,它是逻辑空间中的概念在代码中的对应体;给namespace起名,我知道,它象征了论域,语境.而对这个天上掉下来的class,我实在无法想象它是以什么身份出现在我这的

      嗯,先说这些,冒号老师你怎么看?

      呃,再多说一句,我至今很奇怪,我几乎没有听闻在这个设计上有引起争议?(也可能是我的信息范围比较小吧,呵呵)

    • #1329
      hui
      Keymaster

      这个问题在《冒号课堂》曾经提过,以下引自6.1章节中的一段话——

      OOP又不是金子,含量越高越好。试图把一切都装进OOP的箱子里的想法无异于削足适履。典型的如Java中的Math类,逻辑上压根儿就不存在什么Math对象,清一色的static方法和常量就是最好的讽刺。在C++中只要在math的namespace中定义一些自由函数就可以了,自然而简洁。

      对此设计表示不满的人肯定是有的,只是Java更多地用来写较大型程序,使用者大多习惯了java的一些冗余设计。在OOP语言中,除了C++、python、ruby等以外,Java的脚本版(粗略这么说吧)Groovy语言也是允许自由函数的存在的。毕竟,人们还是更喜欢简洁而自然的代码的。

    • #1330
      Lumj
      Member

      嗯,对的,我记得你提过的这段话,很有印象

      一些使用者”习惯了”?嗯..我怎么感觉这个设计带来的麻烦真的不少啊,不仅是冗余了

      在Utility class之类的static class中,放一些函数,每个加上static修饰,此为”冗余”,然后调用时的代码的外观确是不冗余(Utility.SomeMethod()),但它毕竟是class,强人所难,如果在Utility里有需要作进一步划分,比如,Math.Calculas,Math.Geometry,那继续拿着这个class就吃力了(内嵌的static class?),如果放弃的话,那些函数就只能在同一层级上.这岂不就不只是代码简不简洁的问题了?它影响到设计了啊

      根本上,class本就不是希望让人这样使用的吧,岂不是得了锤子,一切都成了钉子?

      我与身边的人讨论这个问题的时候,理由大抵是”为了模块化”,”这是OOP”,”为了避免名字冲突”这3个

      然后我就说,”OOP?这和OOP一点边都搭不上,’O’,object,敢问这个Math里哪有object?”

    • #1331
      hui
      Keymaster

      Java后来引进了static import,C#也增加了static class,在一定程度上缓解了代码冗余。至于当初为何如此设计,恐怕是为了强调“一切都是对象”,以有别于C++中“臭名昭著”的过程式与对象式的混用。这里面恐怕不全出于技术方面的原因,也是一种宣传的噱头,故此不少人认为OOP是一种hype。

    • #1332
      Lumj
      Member

      嗯,不过static import只使得引用函数时不需要全名,而这一定程度上可以说使得事情变得更加难以理解;c# static class更是对缓解代码冗余毫无帮助(初识c# static class时我还期望它能以一个static省去class内的所有static,后来发现原来仍然不能省略,这static只是作检查确保所有成员皆static(嗯,这点还算是积极的)),而且根本上这个class仍以一种十分不可理解的身份出现,一点也没有变好

      “hype”,呵呵,我感觉这是不小的遗憾啊!

      哦,对了,你提到

      C++中“臭名昭著”的过程式与对象式的混用

      呃..其实每次看到这样的陈述我都很迷惑,我会想,事情不就该是这样的吗?”过程”与”对象”为什么会被认为是互斥的???冒号老师能说说么?

      我想程序本就是对”要做些什么”的描述,本是动作性的,而OOP语言帮助人把脑中的概念映射为代码中的class,使得可以以一种相当直接的方式来表达,并自然形成局部的”对象性”的(相对于动作性)静态的具有声明语义(相对于动作流语义)的..”东西”(不想用”对象”这个词,怕混了),但这又怎能影响程序的动作性这一全局本质呢?不可能因为这一点,程序本身就成为对某个”东西”进行声明了

      呃..先说这些吧,我怕没说到点子上或者我对那再修词语的理解有问题,期待老师阐释一下!

    • #1333
      Lumj
      Member

      最后一行打错了,是”两个词语”

    • #1334
      hui
      Keymaster

      C++中“臭名昭著”的过程式与对象式的混用

      我特意在“臭名昭著”四个字上加上引号,便表示本人并不赞同这个说法。“过程”与“对象”当然不是互斥的,在《冒号课堂》中关于编程范式的分类中对此已作过说明。对于Java、C#等语言来说,整体设计采用的对象式思维,具体实现对象的每个方法则是过程式思维。至于你提到程序的动作性,这个也不是绝对的。比如prolog是纯声明式语言(更具体地,是逻辑式语言),不需要对”要做些什么”进行描述,只需要罗列一些规则、事实和目标即可,具体的程序执行动作由解释器自动完成。

    • #1335
      Lumj
      Member

      哦..嗯,我也不赞同,我觉得很奇怪

      嗯,我知道,我正是说对于java或c#这样的非声明式的语言来说,动作性是不可能改变的本质

      我觉得纯过程式的程序的运行是建立状态然后控制它以可以完成问题逻辑的方式不断地进行状态的切换,对象式的程序首先本质上与它无异,然后它另提供了把问题中凸显出的具有明显特征的”状态-过程”组抽出并敛起的工具.仅此罢了.但由此人可以把具有密切关联的”状态-过程”组凝聚成簇,然后把它作为一个状态管理单位来管理,就好像在有些google maps应用中当Marker太多时会凝聚成簇的那种感觉一样,而周围仍然有散落的小Marker.所以我觉得如果我们站在一个object的方法内部,我们应该无法判断自己是在一个object的方法内部的流程中还是在所谓的”全局”流程中.强迫把每个函数都装进class实在很没有道理

    • #1336
      Lumj
      Member

      其实,如果这样设计,我便觉得完全可以接受:

      一个可执行程序需要实现一个Program class,完成其中的start方法以作为程序的入口点——这类似j2me中的MIDlet

      因为这时这个class的意义明确,启动程序被看作实例化一个代表这个程序的对象,没有任何思维上的生造

    • #1337
      Lumj
      Member

      接上面——即使这时一个可执行程序(而不是dll模块)的代码的语义成为了声明式的

Viewing 9 reply threads
  • You must be logged in to reply to this topic.
 请您评分1星(很差)2星(不行)3星(一般)4星(不错)5星(很棒)