鸡肋 java Optional

转载

游侠小影 2024-12-10 13:34:46

文章标签 鸡肋 java Optional C# vb.net .net 编译器 文章分类 Java 后端开发

在网上经常能看到一些评论和比较C#、VB.net优劣的文章。其中绝大多数都认为：VB.net没有它存在的必要，VB.net迟早要被C#取代。确实，计算机语言不是很重要的，也许讨论它有点无聊。所以还希望那些“心中无剑”、“架构、思想至尚”的高手们口下留情。关于VB.net与C#在功能、能力、面向对象的特性上，实在是难分伯仲。这个已是不争的事实。尤其是VS.net2005中，这两种语言已经达到了惊人地相似！

下面就通过三个大方面对这这两种语言进行比较：

一、语言的人性化区别

C#像傻男人，VB.net像聪明贤惠的女人，从代码的风格就可以看出。

例1. 声明变量时：
C#: int iTest ; //很直接的语气，类似于：擦汗！拿毛巾

VB.net： Dim iTest As Integer ‘很委婉的语气，类似于：小王，给我拿条毛巾，我用它擦汗。

实现完全相同的功能，但有着很明显的区别。哪个更人性化、更易懂呢？声明变量C#好点，够简洁，不用打太多代码，尽管现在书写dim a as string可以3秒内打出

       例2.语言的关键字上：
       C#关键字：
       using、this、void、base、abstract、sealed、virtual、switch、internal、static

相应的VB.net关键字：
Imports、Me、Sub、MyBase、MustInherit、NotOverridable、MustOverride、Select 、Friend、Shared

比较一下，C#的关键字比较冰冷，是具有一定“机器味道”的语言。而VB.net的关键字，都是“人的行为”，“人的称谓”。相信VB.net的语法更具亲和力，更易于帮助我们理解面向对象的特性。

二、语言的先进性的对比

现在，计算机软件工程越来越庞大，已经远远不是10年前的几十KB大小的级别了。这就对语言的可扩展性、可辅助性提出了更高的要求。“面向对象”便是这个需求的一个产物。从现有的语言来看，具有“标识符”的标识性语言具备更高的容错性、可调试性、可扩展性。比如HTML、XML。尤其是XML已经成为了下一代语言的模型。

为什么像HTML、XML这种具有“开口”和“封口”的语言有更高的容错性、可调试性呢？这要取决于它的“吝啬”性。“开口”和“封口”可以把故障的范围最小化，使出现问题的部分尽量不影响其它部分。比如说：在HTML的<table>中，少写一个<TR>多写一个<TR>均不会对表格中其它行造成太大的影响。与这种“吝啬”的语法相反的是“贪婪”性的语法。什么是“贪婪”性呢？这个问题也不太好解释。不过，这种特性与正则表达式的解析十分十分地一致。“吝啬性”的正则表达式用做精确匹配Group时有着较高的性能，而“贪婪性”的正则表达式用于判断IsMatch时有着较高的性能。

像C类的所有封口均使用大括号的语言，就属于这种“贪婪性”的语言。过多相同的封口使得代码更加地难于控制。许多人抱怨微软，为什么不给C#加上动态编译、加上自动完成……，实际上，微软何尝不想加啊，但由于C#的语法特性，是根本无法实现的。下面就用实例来说明为什么C#无法实现动态编译，看下面的C#代码段，代码中的大括号是不平衡的：

class   A   {
       class  B   {
               class   C
               {
                       int   F1()
                       {
                               return   1;
                       }
                       int  F2()
                       {
                               return   2;
                       }
               }
}

假如现在已经有了C#的动态编译器，现在要求编译器指明到底是哪里丢失了大括号！这时，编译器就糊涂了，因为不论是把大括号加在F1的末尾还是加在class A的末尾都是行得通的，虽然这两种情况的意义是完全不同的，即不能判断F1到底是Class C的方法，还是Class B的方法。那么连带下一步，在代码的其它部分就更无法判断调用F1的代码的合理性了。

这里只是举了一个简单的例子，实际的情况比这个更复杂。我们可以看到，在C语言的代码没有完全正确地书写之前，它的结构是有可能极度混乱、多意性的，在这种极度混乱的环境下是无法判断故障之所在、无法正确识别对象的结构的。自然，这样的动态编译器也就成了“累赘”。

相比之下，同样的内容看看VB语法：

Class  A
Class  B
Class  C
Function   X1()  As   Integer
Return  1
End  Function
End  Class
Function   X2()  As   Integer
Return  2
End  Function
End  Class
End  Class

无论你删除End Class还是删除End function，故障范围都不会扩大，定位就可以做到精准。检错如此，自动完成代码也是如此。在C#环境下，由于代码结构可能存在着“多意性”，所以IDE有可能无法决定做处理的确切位置。

当然，C类的代码并不是没有优点，其优点主要有二：

1.节省代码所占的磁盘和内存空间

2.使编译器的体积能够做得更小（最终还是为了节省磁盘空间）

只有在内存和磁盘空间非常珍贵的过去的年代里，C类语言代码才能够更具优势。然而在内存和磁盘如此丰富的今天，这种优势已经成了劣势。借助于这种具有确定的“开口”与“封口”的特性，相信VB.net会走得更远。

第一次接触C#的时候被各种符号搞晕，不过后来就习惯了

三、语言的灵活性、适应性的对比

C#的代码，可以“随便书写”：在一行里可以写多条语句，一条语句可以分成多行来写。这使得它的代码有可能更加地“松散”。虽然C#允许您把代码写得非常地松散，不过在实际的使用中，几乎所有的使用者都默默地走向了VB的代码风格（一行一条语句）。最后，它的分号成了累赘。虽然C#的代码更加地自由，不过C#的思想比起VB.net起来却是更加地死板。在这方面，我觉得把C#比做手动档汽车，把VB.net比做自动档汽车是比较合适的。自动档汽车也可以用手动档的方式驾驶。C#的思想、思路在VB.net中均可实现，而VB.net的思想（自动档）却经常无法在C#上实现。下面举例说明：

例1.事件模型

在C#中，事件模型是固定的，构造一个事件模型通常需要下面的思路：

建立事件代理结构、声明事件、建立事件处理方法、添加事件句柄、判断事件代理是否挂到实例上、通过代理方法引发事件。

在VB.net中，即可以按照C#所用的模式建立事件，也可以用VB.net自身所带的RaiseEvent方法实现。虽然他们编译后的结构几乎是一样的，但毕竟VB.net让我们有了更多的选择，何乐而不为呢？下面就看看VB.net引发事件的两种方法示例：

方法一：用RaiseEvent.
这是一种非常快捷、代码思路非常清晰的一种方法：

Class   EventClass
    Public   Event   E1(sender   as   Object,e   as   XXXEventHandler)
    Sub   XXXX()
        RaiseEvent   E1(Me,new   XXXEventHandler(…)
    End   Sub
End   Class

方法二：用C#的的思路

Public  Delegate   Sub   xxxHandler(ByVal   sender  As   Object,   ByVal  e   As   EventArgs)
Public   Class  A
Public   Event   XXX   As   xxxHandler
Public   Overridable   Sub   OnXXXEvent(ByVal   sender  As   Object,   ByVal  e   As   EventArgs)
    If  XXXEvent   IsNot   Nothing  Then
        XXXEvent.Invoke(sender,   e)
    End  If
End   Sub
Sub   X()
    OnXXXEvent(Me,   New   EventArgs)
End   Sub
End   Class

”用尽量少的代码做出更多的事情“是每个人程序员的最爱！很显然，VB.net在这方面占尽了优势。

       例2.可选参数结构
       如下代码展示了VB特有的结构：可选参数
       Public Sub XXX(P1 As Integer,Optional P2 As String,Optional P3 As String)

End Sub
这样的结构在C#中是无法实现的，但可以通过“重载”的方式实现相同的效果：

void XXX(int P1){}

void XXX(int P1,string P2){}

void XXX(int P1,string P2,string P3{}

当然，用VB.net也可以用重载方式写出一模一样的结构。

这里我反而更喜欢C#的方式，因为不用在一个子过程写上各种判断，分开来还好看和注释。

例3.事件代理的挂接

C#中：只有一种方法：XXX.XXX += new XXX(…);

VB.net中：即可以效仿C#的方法：AddHandler(XXX.xxx,AddressOf XXX)

也可以把过程显示地指定给某个事件：Sub(…) Handles XXX.XXX

利用上述特性，可以实现在VB.net代码编辑页中简单地通过下拉框来精确地定位某个对象的特定事件的处理过程。

遗憾的是，这种方便的特性在C#中是无法实现的。因为C#的语法：XXX.XXX+= 的后面可以是任何方法返回的具有相同签名的实例。比如通过属性、方法，甚至是随机判断后返回的。这种“过份的自由”使得C#编译器在运行代码前不能准确地确定该对象事件的处理部位。类似的例子太多了，举不胜举。总之，VB.net给了我们更大的活动空间，它允许我们在“更快的速度”和“更严格性能要求之间自由选择。

四、代码书写上的比较
1.变量的命名的区别

C#是区分变量的大小写的，这一点着实让人摸不着门。也许这仅仅是为了效仿Java?在公共语言规范中(CLS)，明确规定“变量不区分大小写”的，真是难为了C#编译器，还要把“重名”的变量重新命名。

相比之下，VB.net更加符合CLS，而且因为不区分大小写，编辑器就更轻松地实现了“自动更正”功能。

C#绝对是“嫁错了人”。C要区分大小写，其原因有二：一是为了能使用更多的变量资源，二是为了节省编译器的开销（性能和体积上都节省）。

如今，.net环境允许我们使用多达1024个长度的变量名，而且已完全面向对象化，相同的变量可以同时出现在任何object中，所以可用的变量资源数量理论上已经达到了无穷多个！在这样的条件下，“区分大小写”使代码在可读性、可调试性、可辅助性上都造成了不小的负面影响！它已经成为了语言发展的障碍！

C#的区分大小写完全是坑爹的，写代码的时候非常要用很多“脑存”

2.代码的书写

几乎绝大多数的C#程序员都觉得他们在代码的书写上有着无与伦比的优越性，因为C#代码看上去是如此的简洁。是的，如果我们仅使用记事本来开发.net应用程序，我相信像VB、Delphi早就灭绝了。但更糟糕的是：如果我们仅能使用记事本写代码，那么程序员也早就集体自杀了。说多少也不会有人相信，尤其是C#程序员不会相信：在代码书写方面他们会完败于VB.net程序员。我们完全可以用“键盘钩子”做个小程序来检测、验证一下到底是哪种代码更浪费键盘、书写起来更吃力。

测试结果很明显：VB.net代码需要按键的次数更少、书写更为容易。原因是IDE在其中起到了极大的作用！

VB.net不必像C#那样不停地用Ctrl+shift+B来编译检错；不必不停地按下Shift键来输入星罗棋布的符号；不必不停地使用Ctrl+]徘徊于大括号之间；更不必手动输入众多的“关闭符”。（试一试：输入If A=B [回车]，这时 Then和End IF马上就都给你准备好了）(再试一试：在一个刚刚建立的新Class中，输入Inherits后回车，所有需要实现的方法都给你准备好了)

究其本质，是由于VB.net的语言起到了决定性的作用。

正是因为我们已经告诉了编辑器“这是一个ReadOnly Property”，所以编辑器会给我们自动提供了Get结构代码；

正是因为我们已经告诉了编辑器“这是一个WithEvents的对象”，所以编辑器会在对象事件选择列表里加入它；

正是因为我们已经告诉了编辑器“这是一个Event”，所以当我们要RaiseEvent时，它会准确地出现在列表中；

正是因为我们已经告诉了编辑器“这是一个Function”，所以当我们写上调用方法后，它会自动地在后面加上括号；

反观C#，由于代码过度地萎缩，许多事情还需要通过分析整段代码的结构来决定它的属性，导致这些“智能的操作”无法在C#上实现。

五、总结

由于C#语言是基于符号的语言，这就决定了它的可扩展性比较弱(所有的符号都让C#给用过了，如果再扩展，还能用什么呢？像C++那样，把-->和::这种组合符号也搬上来吗？)
相反，VB.net会有更多的特性、更大的潜力有待于发挥。

用马克思的理论来衡量这两种语言：具有发展前途的事物称之为“新事物”。而VB.net正是这种“新事物”。

现在看C#语言：说方便性，比VB.net差；论性能，比C++差；谈跨平台通用性，比Java差，C#实际上是一种过度性的、鸡肋的计算机语言。

从C++到C#，更多的体会是：委曲求全。

从VB到VB.net，更多的体会是：如鱼得水！