怎么在VEE中进行VEE编程

>我错过了什么吗？不，你不是。
Jeez，连续两次必然会让我遇到麻烦！不，它不支持一些概念。
事实上，它并不支持任何。迄今为止，任何OO语言的特性绝对没有任何特征。
除了弱形式的封装之外。
我不关心营销文献所说的内容 - 这些人拥有商业，心理学和（上帝禁止）文科学位，而不是计算机科学。
VEE最重要的不是面向对象。
完全没有。
仅仅因为它是用面向对象的语言编写的并不意味着它本身就展示了任何OOness。
如果有人想说VEE引入它自己的OOP类型那么我就没问题，但是通过其他比例它几乎为零。现在，我已经说过让我也说没有什么可以禁止在VEE编程中使用OO主体 -
就像其他所有类型的编程一样。
这种技术可以产生差异，而不是语言（我知道你顺便通过这种方式得到了这个）。
语言可以阻碍或帮助努力，但它不会成功或破坏技术。举个例子：多态性。
考虑一个原始案例：C ++重载。
VEE具有Any类型，typeName函数返回Any的基本类型。
因此，您可以根据类型执行不同的操作：C ++重载。
当然假设这些Anys是函数或“对象”的输入。现在，对于* real *多态。
我实际上已经看到了动态生成代码的例程，然后根据条件执行它。
具体来说，传递给函数的参数值，但该技术可以扩展到程序生成器类型场景，该场景将复制vtable的功能。
这并不像你会得到任何你想要的执行速度，但你可以建立一个多态函数生成器/执行器。这是另一个例子：C。我认识的任何人都不会声称C特别面向对象。
事实上，这是一种阻碍概念而不是帮助它的语言。
然而，在Bjorn踩到他的脚趾之前，人们在C语言中进行面向对象编程（或者不过故事情节）。
Windows是完全封装的，甚至是多态的，但它是用C语言编写的，直到最近才开始使用几乎全部的C API。
DCE RPC几乎是OO的典型代表。
人们几乎可以直接从RPC.Ever看到COM萌芽，因为VEE 5你可以完全忽略VEE并根据需要用对象做所有的VEE编程。
而且现在你也可以使用.NET而忽略另一条思路中的VEE。这些抽象中没有一个真正意味着什么。
有时它们可​​以提供帮助，但更常见的是它们会阻碍或隐藏。
只要问任何熟悉MFC的人。
这是一种爱/恨的东西，直接进入它的“面向对象”的核心。隐藏更有帮助，虽然这也是坏点。
你不需要*知道VB Collection真的是一个链表。
继续开始使用数十或数十万个条目，您很快就会发现一系列结构是更好的选择。
VB字符串也是如此。
不要试图反复长大，否则你会发现你的胡子在你的磁盘捶打时会长出来。简而言之，如果情况有所保证，那么一定要在VEE中使用OO。
同样，如果情况需要，那么在VEE中使用模式。
有时候忽略所有这些抽象并且只是在VEE中进行VEE编程是明智的。
就像我说的那样，木工不是你在木材场所找到的东西！-SHAWN-



     以下为原文

  > Am I missing something?

No you're not. Jeez, two in a row that are bound to get me in trouble!

No it doesn't support some of the concepts. In fact, it doesn't support any.

VEE exhibits absolutely NONE of the characteristics of any OO language to date. With the possible exception of a weak form of encapsulation. I don't care what the marketing literature says - these people carry degrees in business, psychology and (god forbid) liberal arts, not computer science. VEE is most emphatically not object oriented. At all. Just because it's written in an object oriented language doesn't mean it exhibits any OOness itself. If one wants to argue that VEE introduces it's own type of OOP then that's fine by me, but by other scales it scores almost zero.

Now, having said that let me also say that there's nothing forbidding the use of OO principals in VEE programming - just like every other kind of programming. It's the technique that makes the difference, not the language (I realize you get this by your verbiage by the way). The language can hinder or help the effort, but it doesn't make or break the technique.

Take your example: polymorphism. Consider a primitive case: C++ overloading. VEE has the Any type, and the typeName function returns the base type of Any. Therefore you can perform different actions depending on type: C++ overloading. Assuming of course that these Anys are inputs to a function or "object".

Now, for *real* polymorphism. I've actually seen routines that generate code on the fly and then execute it depending on conditions. Specifically, the value of parameters passed to a function, but the technique can be expanded to a program generator type scenario that would duplicate the function of a vtable. It's not like you're going to get anything like the speed of execution you'd want, but you could build a polymorphic function generator/executor.

Here's another example: C. Nobody I know would claim that C is particularly object oriented. This is in fact a language that hinders the concept more than helps it. And yet people were doing object oriented programming in C long before Bjorn stubbed his toe (or however the story goes). Windows is quite encapsulated and even polymorphic and yet it was written in C and up until recently sported an almost exclusively C API. The DCE RPC is almost a poster child for OO. One can almost see COM sprouting directly from RPC.

Ever since VEE 5 you can ignore VEE completely and do all your VEE programming with objects if you want. And now you can use .NET too and ignore VEE along another line of thought.

None of these abstractions really mean anything anyway. Sometimes they can help, but more often they hinder or hide. Just ask anybody who's familiar with MFC. It's a love/hate thing that goes right to the core of it's "object orientation".

The hiding is much more helpful, though that has it's bad points too. You don't *need* to know that a VB Collection is really a single linked list. Just go ahead and start using tens or hundreds of thousands of entries and you quickly find that an array of structures is a whole lot better choice. Same thing with a VB String. Don't try to grow it repeatedly or you'll find your beard growing while your disk thrashes.

In short, and as always, if the situation warrants then by all means use OO in VEE. Equally, if the situation warrants then use Patterns in VEE. Sometimes it's prudent to ignore all such abstractions and simply do VEE programming in VEE. Like I said, carpentry is not something you find in a lumber yard!
-SHAWN-