VBScript中的类：为什么这两个例子做同样的事情？ [英] Classes in VBScript: Why do these two examples do the same thing?

问题描述

我在StackOverFlow问题上找到这段代码，对象/类的词典VBScript 。

我的问题是为什么这个short类和这个long类做同样的事情？为什么甚至打扰长类？短类版本可以与同一类中的其他方法一起使用吗？非常感谢！

短班

 班级第一，最后，工资
结束类
  

长类

 职业类别
私人m_first 
私人m_last 
私人m_salary 
 
公共财产$ b first = m_first 
结束属性
公共属性首先（值）
 m_first =值
结束属性
 
公共属性获取最后
 last = m_last 
结束属性
公共属性让最后一个值（值）
 m_last = value 
结束属性
 
公共属性获取工资
 salary = m_salary 
结束属性
公共属性让工资（值）
 m_salary =值
结束属性
结束类
  

使用短类的完整脚本，但是，只需用短类替换短类，得到相同的结果。

 类Employeeclass 
公共第一，最后，工资
结束类
 
 Dim employeedict：Set employeedict = CreateObject Scripting.Dictionary）
 
 Dim employee：Set employee = new employeeclass 
 with employee 
 .first =John
 .last =Doe
 .salary = 50000 
结束于
 employeedict.Add1，雇员
 
设置employee = new employeeclass 
与employee 
 .first = Mary
 .last =Jane
 .salary = 50000 
结束于
 employeedict.Add3，雇员
 
 Dim employeedetails：Set employeedetails = employeedict.Item（1）
 WScript.EchoName：&第一& &使用$& employeedetails.salary 
 WScript.Echo employeedict.Item（3）。 & employeedict.Item（3）。last& make $& employeedict.Item（3）。salary 
  

解决方案

编程范式（开发软件的不同方式）努力以更少的努力建立更好的程序。然而，概念更好和努力不太严格地定义为数学术语，并且它们的核心含义随时间改变。

OOP的基本思想是捆绑复杂数据（如处理员工所需的信息）具有复杂功能（如操纵此类信息所需的操作）。在OOP之前，你可以有员工结构/记录/类型和漂亮的函数/订阅/程序来提高员工的工资，但程序员负责以正确的方式将正确的函数应用到正确的数据。

在这个基础上，OOP可以提供进一步的好处，提高软件质量，减少努力和错误的风险，特别是在大团队创建和重新使用大型系统的软件组件：

1. 自动调用析构函数进行内存管理（例如C ++;其他语言 - 包含VBScript） >
   
2. 继承代码重用（例如Java; VBScript对象不能继承，你必须将对象嵌入对象以获得类似的效果）


3. 
   
   

   您的第一个（短）类有数据，但是没有方法。让我们添加一个init函数：

    公共函数init（p_first，p_last，p_salary）
   设置init = Me 
    first = p_first：last = p_last：salary = p_salary 
   结束函式
     

   得到10个员工你可以写10次

    设置employeedict（nId）= new employeeclass.init（John，Doe ，12345.67）
     

   而不是10次

     Dim employee：Set employee = new employeeclass 
    with employee 
    .first =John
    .last =Doe
    .salary = 50000 
   结束于
    employeedict.Add1，雇员
     

   
   
   让我们想象一个raiseSalary方法，它做一些计算（基于cents不是
   美元为了以后的参数）

     Sub raiseSalary（）
   （m_）salary = x *（m_）salary / y ... 
    End Sub 
     

   调用这种方法 - 当一些法律改变时改变公式 - 肯定有40行，像

     employeeX.salary = x *（m_）salary / y ... 
     

   
   
   <在你的脚本。 （这只是功能抽象，而不是OOP;在C ++或Java中，很容易/自动地让你的老板的薪水计算不同的公式（多态函数）当你处理一个长列表的雇员 - 在VBScript你会有）

   
   
   

   您的第二个（长）类具有 - 锅炉板 - 用于控制数据访问的方法（属性），但没有有效载荷功能（如raiseSalary）。只要你不为setter添加有趣的东西（输入验证，转换（例如美元到美分）和现实世界的可用方法，长类只是一个浪费编码时间（当然，如果你支付代码行/小时，你的经理没有意识到这个类，因为它不防止未完成或错误的初始化，很容易，如果不幸得到了钱。）

   
   
   

   init函数garanties完成成员数据的初始化并验证输入（例如合理范围内的双数），并且您的提高薪水公式集中在一个方法中，您可以更改计算以使用更长精度的数字和在init方法中将美元转换为美分 - 在使用该类的代码中没有更改。

   
   
   

   是否应该防止用户直接将工资设置为书籍（私人会员和存取者）或书籍（书面的宣传）的愚蠢价值取决于你的观众。

   
   
   

   总结：

   
   
   1. 类应该具有有效负载方法
   
   
   2. 即使在VBScript脚本上下文中（一个程序员，许多临时性的脚本，特定任务，很少可重复使用的组件/模块，不完全支持OOP功能）在更好的类（使用init函数，输入验证，核心功能的集中实现）组织代码是一件好事。
   
   

   
   

   I found this piece of code on this StackOverFlow question, Dictionary of Objects/Classes in VBScript.

   My question is why does this "short" class do the same thing as this "long" class? Why even bother coding the long class? Could the short class version be used with additional methods within the same class? Thanks!

   Short class

   Class employeeclass
       Public first, last, salary
   End Class
   

   Long Class

   Class employeeclass
       Private m_first
       Private m_last
       Private m_salary
   
       Public Property Get first
           first = m_first
       End Property
       Public Property Let first(value)
           m_first = value
       End Property
   
       Public Property Get last
           last = m_last
       End Property
       Public Property Let last(value)
           m_last = value
       End Property
   
       Public Property Get salary
           salary = m_salary
       End Property
       Public Property Let salary(value)
           m_salary = value
       End Property
   End Class
   

   Full script with the short class however, just replace the short class with the long class an get the same result.

   Class employeeclass
       Public first, last, salary
   End Class
   
   Dim employeedict: Set employeedict = CreateObject("Scripting.Dictionary")
   
   Dim employee: Set employee = new employeeclass
   With employee
       .first = "John"
       .last = "Doe"
       .salary = 50000
   End With
   employeedict.Add "1", employee
   
   Set employee = new employeeclass
   With employee
       .first = "Mary"
       .last = "Jane"
       .salary = 50000
   End With
   employeedict.Add "3", employee
   
   Dim employeedetails: Set employeedetails = employeedict.Item("1")
   WScript.Echo "Name: " & employeedetails.first & " " & employeedetails.last & " $" & employeedetails.salary 
   WScript.Echo employeedict.Item("3").first & " " & employeedict.Item("3").last & " makes $" & employeedict.Item("3").salary
   

   解决方案

   All programming paradigms (different ways of developing software) strive to build better programs with less effort. The concepts "better" and "effort", however, are less strictly defined as mathematical terms and their core meanings change over time.

   The basic idea of OOP is to bundle complex data (like the info needed to deal with employees) with complex functionality (like the actions needed to manipulate such info). Before OOP you could have employee structs/records/types and nifty functions/subs/procedures to raise an employee's salary, but the programmer was responsible for applying the correct function to the correct data in the correct way.

   Building on this base, OOP can provide further benefits that increase software quality and reduce efforts and risk of errors especially in the context of big teams creating and re-using large systems of software components:

   1. memory management by calling destructors automatically (e.g. C++; other languages - VBScript included - use garbage collection instead)
   2. code re-use by inheritance (e.g. Java; VBScript objects can't inherit, you'll have to embed objects into objects to get a similar effect)
   3. information hiding/controlling access to reduce risk of errors and make improvements of implementations possible

   Your first (short) class has data, but no methods. Let's add an init function:

   Public Function init(p_first, p_last, p_salary)
     Set init = Me
     first = p_first : last = p_last : salary = p_salary
   End Function
   

   So to get 10 employees you can write 10 times

   Set employeedict(nId) = new employeeclass.init("John", "Doe", 12345.67)
   

   instead of 10 times

   Dim employee: Set employee = new employeeclass
   With employee
       .first = "John"
       .last = "Doe"
       .salary = 50000
   End With
   employeedict.Add "1", employee
   

   Now let's imagine a raiseSalary method that does some computations (based on cents not dollars for the sake of a later argument)

   Sub raiseSalary()
     (m_)salary = x * (m_)salary / y ...
   End Sub
   

   Calling this method - and changing the formular once when some law changes - certainly beats having 40 lines like

   employeeX.salary = x * (m_)salary / y ...
   

   scattered all over your script. (This is just functional abstraction, not OOP; in C++ or Java it would be easy/automagically to have the boss' salary calculated by a different formula (polymorphic function) when you process a long list of employees - in VBScript you'll have to resort to dirty/risky tricks involving duck typing.)

   Your second (long) class has - boiler plate - methods (properties) for controlling data access, but no payload functionality (like raiseSalary). As long as you don't add interesting things to the setters (input validation, conversions (e.g. dollars to cents) and real world usable methods, the long class is just a waste of coding time. (Of course, if you are payed by code line/hour and your manager does not realize the class as it is does not guard against incomplete or wrong initializations, it's easy if ill gotten money.)

   But if your init function garanties complete initialization of member data and validates input (e.g. double number in plausible range) and your raise-the-salary formula is centralized in one method, you could change the computation to use long numbers for better accuracy and convert dollars to cents once in the init method - with no change in the code that uses the class.

   Whether you should guard against users setting the salary directly to stupid values by the book (private members and accessors) or by book (documented admonishments) depends on your audience.

   To sum up:

   1. Classes should have payload methods
   2. Getters/Setters without at least some additional features above just storing parameters/returning member data are useless
   3. Even in a VBScript scripting context (one programmer, many ad hoc scripts for specific tasks, few re-usable components/modules, incomplete support of OOP features) organizing your code in 'better' classes (with init functions, input validation, centralized implementation of core functionality) is a good thing.

   这篇关于VBScript中的类：为什么这两个例子做同样的事情？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！