Visual Basic 的未来之三(转)

语言上的改进

长期以来，在喜欢Visual Basic的程序开发者和喜欢另外一些更“复杂”的语言的程序员之间的关系一直都很紧张。我不止一次的为我所最爱的编程语言反驳诸如”玩具语言”之类的控诉，他们认为Visual Basic缺乏OOP的特征。

好，那么猜猜发生了什么？下一个版本的Visual Basic将最终结束他们的抱怨。Microsoft计划加入面向对象编程的三大特性：继承性、多态性和重载。这还不是所有！另外一些结构，包括结构化的错误处理和浏览也将被引入Visual Basic语言。

继承性的特性允许你设计一个基类，然后编写一些派生类，它们继承基类的功能，这样做可以节约时间，并提高程序的可重用性。例如，你编写了一个名叫BaseClass的基类，它有一个函数：

Function GetCustomerName()
' Do some stuff
End Function

现在你想再写一个类，它可以象调用本身的函数一样调用基类的GetCustomerName函数。过去的方法是什么呢？这在过去没有办法。然而，现在的新的方法只需在新的类的上面插入如下简单的一行语句：

Inherits BaseClass
Function GetCustomerID()
' Do some stuff
End Function

编写两个或更多的名字相同但具有不同标识符的函数，这就是重载。在某种程度上，Visual Basic在函数调用时对内部类型的转换以及属性的设置中已经实现了重载。比较以下两行有效的Visual Basic 代码：

Text1.Text = "7"
Text1.Text = 7

在这两个调用中，Text1中的text都将被设为字符串“7”。这就是重载调用，因为Visual Basic知道如何处理输入的不同的数据类型。它把它们作为变量处理，并自动进行转化。当你调用一些参数类型有明确定义的函数时，Visual Basic也会作同样的转化。下面的两个函数调用：

a = SetVal("This")
a = SetVal(7)

都可以正确调用以下函数：

Function SetVal(x As String)
Form1.Text1.Text = x
End Function

既然Visual Basic已经可以传送多种不同的变量类型，为什么还需要重载功能呢？这是因为虽然目前单独的一个函数已经可以处理多种数据类型，它不能根据传入的不同的数据类型产生不同的动作。相反的，比较以下两个函数：

Function GetCustomerID(custname as string) As Integer

' Look up customer ID based on customer name
End Function

Function GetCustomerID(purch as long) As Integer
' Look up customer ID based on purchase order
End Function

通过重载，你可以根据输入的数据类型来实现函数。这对于下一个版本的Visual Basic是很重要的，因为它具有一个新的特性――缺省数据类型保护。一般来说变量的自动转换是有利的，但可以想到有时也会给你带来麻烦。例如在前面的SetVal的例子中，如果你要传送的是字符7而不是字符串“7”，那会发生什么情况呢？下一个版本的Visual Basic将会自动捕获这个错误。（如果你的代码是基于Visual Basic以前的无类型识别的功能，这个特性会被禁用）

最后，多态性是对已定义的类的再定义过程。例如，你想写一个BaseClass类的派生类，但你想重新改写GetCustomerName函数。在下一个版本的Visual Basic中，你可以用类似以下这种新方法来实现这种类的定义：(注意：最终的语法取决于正式的版本)

Inherits BaseClass
Function GetOrders()
Overrides Function GetOrders()
•••
End Function

更多的语法特性

下一个版本的Visual Basic可能不仅仅只有我以上提到的那些有关面向对象方面的改进。对于scalability和可重用性而言，还有一些线程生成、错误处理和许多长期以来一直被期待着的新的改进。

目前，Visual Basic支持apartment-threaded模型。虽然这种模型为应用程序的开发提供了真正的高效率，但它还不够理想。下一个版本的Visual Basic将在这方面有所改进。它采用freethreaded模型，这在编写scalable的 网络应用程序时将很有用处。Visual Basic还将包括一些语法结构，你可以用来产生多线程。典型的线程发生操作如下所示：

set t = New Thread(New Threadstart
(AddressOf(BaseClass.Function1))

从这个例子中，可以看到下一个版本的Visual Basic有AddressOf结构，用它来返回函数的地址。你不再被迫跳过那些需要函数指针的API函数了！如果你需要返回调用，你可以利用它来做到这一点。

计划中的另一项改进是结构化的出错处理。不久以前，Visual Basic还要求你在代码中插入大量的On Error声明。多年以来，我一直对插入如此多的GOTO语句感到不安。这些语句一再告诫我不要再使用它们！现在让我们来面对这个问题――我们需要一种出错处理机制。

下一个版本的Visual Basic采用集中处理出错的方式。Visual Basic将象那些“高尚的”语言一样支持 try...catch...finally结构。你可以在你的代码的顶端放置一个包含有出错处理的子程序。这里是实现出错处理的一个例子：

Sub SafeWrite()
Try
Open "Testfile"
•••
Write #1
Catch
Kill "Testfile"
Finally
Close #1
End Try
End Sub

还有一些其他方面令人激动的改进，现在的Visual Basic的使用者将会逐渐熟悉它们。在下一个版本的Visual Basic中，你可以在变量声明的同时对变量进行初始化：

Dim a as integer = 10

你也可以在一个表达式中建立和初始化一个新的对象。你也可以通过类来共享变量。最后，但不仅仅如此，继承的概念扩展到了项目的用户界面的基础。关于Visual Basic的一个具有代表性的观点是它很难在相同的基础上创建多种不同的表单。（在联合开发的环境中，通常有这种要求）。在下一个版本的Visual Basic中，你可以通过模板类型来实现。

多年以来，人们一直期待着这些改进，这是为什么呢？让我们来看看。Visual Basic的通信（在这方面我已经从事了将近十二年）变得越来越复杂，远远超过1991年的第一版。Visual Basic早期最初用于小型的便携式的工具样机的快速设计和开发。结果，Visual Basic获得了“玩具语言”的名声（在我看来，这是意料之外的）。现在它显然不再是玩具了，再这么说的人就是出于一种盲目的偏见了。现在各个领域都有大量的基于Visual Basic的软件包。Visual Basic 正在发展着。去年，在中心研究所，我和一个软件开发者进行了交谈，他使用Web-Class编写的程序每星期接受上百万次的点击。

下一个版本的Visual Basic所发生的变化是令人惊喜的。如果你想获得它们所带来的那些好处，那就使用它们。如果你不想，你可以理直气壮的使用你目前仍然使用的。然而，了解在象Visual Basic这种比C++和Java容易使用的多的语言中，也可以实现C++和Java所实现的功能，是有好处的。

未来的发展趋势

这种预览式的介绍你留下了什么样的印象呢？这个问题问得很好，但是你可以找到问题的答案。在过去的一年中，可以明显的看到ASP开发的变化，这些开发程序常常由一些易读的ASP脚本组成，在这些脚本的基础上运行整个程序。由于ASP是对整个脚本代码进行解释执行的，在对各组件进行组装时，人们逐渐发现这种技术的固有的局限性。我听到越来越多的开发者说，他们要把他们的事件处理函数从脚本代码中完全脱离出来，放在更快捷的编译方式的模型下实现，这些模型用C＋＋或Visual Basic编写，通过COM接口进行组装。

对于你所能想到的各种理由，Visual Basic都是能够满足的。使用Visual Basic来设计组件实际上并不比使用VBScript或JScript®困难多少。你可以编写执行起来更快的代码，并且很容易就能达到你的要求。当下一个版本的Visual Basic发布后，你可以使用Visual Basic来生成面向 网络的对象，这种对象和ASP兼容。总之，走组件组合的路线不管是现在还是将来都会被认为是最好的选择。

正如我前面时候提到的那样，使用Visual Basic(和WebClasses)编写的面向Internet的应用程序已经有很广泛的基础。问题是，大部分的基于WebClasses的应用程序并没有经过很好的设计。它们没有很好地区分应用程序的不同的层次，把中间层的过程和基于DHTML的用户界面混淆了。

下一个版本的Visual Basic将引入WebClasses，它是经过精心挑选后确定的 网络开发的工具。因为它更具有scalable、更强大、而且是真正的language-agnostic。它在Visual Studio的所有的工具中起作用。如果你注意多层开发的一些基本规则，你可以很容易地完成这个转变。特别要注意，把中间层过程和显示层过程分开。强烈推荐在做这些工作时，参考 Windows® DNA 2000的体系结构。核心的事件处理功能必需在中间层完成，你可以使用各种你所喜欢的编译语言编写的用于实现这些功能的各个组件。然后，这些组件组装在一个ASP脚本文件中，这样各组件就可以协同工作了。如果你把大部分的逻辑运算放在事件对象中而不是脚本中的话，那就是最理想的了。它不仅对将来向Web services转变是一个好的主意，它也是一种值得效仿的实践。[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8781179/viewspace-925236/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8781179/viewspace-925236/