5

この StackOverFlow の質問、Dictionary of Objects/Classes in VBScriptでこのコードを見つけました。

私の質問は、なぜこの「短い」クラスがこの「長い」クラスと同じことをするのですか? なぜわざわざ長いクラスをコーディングするのでしょうか? ショート クラス バージョンは、同じクラス内の追加のメソッドで使用できますか? ありがとう！

ショートクラス

Class employeeclass
    Public first, last, salary
End 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

ただし、短いクラスを使用した完全なスクリプトは、短いクラスを長いクラスに置き換えるだけで同じ結果が得られます。

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
4

3 に答える 3

7

すべてのプログラミング パラダイム (さまざまなソフトウェア開発方法) は、少ない労力でより優れたプログラムを構築するよう努めています。ただし、「より良い」および「努力」という概念は、数学用語としてあまり厳密に定義されておらず、その核となる意味は時間の経過とともに変化します。

OOP の基本的な考え方は、複雑なデータ (従業員に対処するために必要な情報など) と複雑な機能 (そのような情報を操作するために必要なアクションなど) をバンドルすることです。OOP の前は、従業員の構造体/レコード/タイプと気の利いた関数/サブルーチン/プロシージャを使用して従業員の給与を上げることができましたが、プログラマは正しい関数を正しい方法で正しいデータに適用する責任がありました。

このベースに基づいて、OOP は、ソフトウェアの品質を向上させ、特に大規模なチームがソフトウェア コンポーネントの大規模なシステムを作成および再利用するというコンテキストで、労力とエラーのリスクを軽減するというさらなる利点を提供できます。

  1. デストラクタを自動的に呼び出すことによるメモリ管理 (例: C++; 他の言語 - VBScript を含む - 代わりにガベージ コレクションを使用)
  2. 継承によるコードの再利用 (例: Java; VBScript オブジェクトは継承できません。同様の効果を得るには、オブジェクトをオブジェクトに埋め込む必要があります)
  3. エラーのリスクを軽減し、実装の改善を可能にするための情報の隠蔽/アクセスの制御

最初の (短い) クラスにはデータがありますが、メソッドはありません。init 関数を追加しましょう。

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

10人の従業員を得るには、10回書くことができます

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

10回ではなく

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

次に、いくつかの計算を行う raiseSalary メソッドを想像してみましょう (後の引数のために、ドルではなくセントに基づいています)。

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

このメソッドを呼び出して、いくつかの法律が変更されたときにフォーミュラを1回変更すると、

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

スクリプト全体に散らばっています。(これは単なる関数の抽象化であり、OOP ではありません。C++ または Java では、従業員の長いリストを処理するときに、別の式 (多形関数) によって上司の給与を簡単に/自動的に計算できます。VBScript では、ダックタイピングを含む汚い/危険なトリックに頼る.)

2 番目の (長い) クラスには、ボイラー プレート - データ アクセスを制御するためのメソッド (プロパティ) がありますが、ペイロード機能 (raiseSalary など) はありません。セッターに興味深いもの (入力の検証、変換 (ドルからセントなど)、実際に使用できるメソッド) を追加しない限り、長いクラスはコーディング時間の無駄です。コード行/時間とあなたのマネージャーは、不完全または間違った初期化から保護されていないため、クラスを認識していません。

しかし、init 関数がメンバー データの完全な初期化を保証し、入力 (妥当な範囲内の 2 倍の数値など) を検証し、昇給式が 1 つの方法で集中化されている場合は、計算を変更して精度を高めるために長い数値を使用し、変換することができます。クラスを使用するコードを変更せずに、init メソッドでドルからセントに変換します。

ユーザーが本 (プライベート メンバーおよびアクセサ) または本 (文書化された警告) によって給与を愚かな値に直接設定することを防ぐ必要があるかどうかは、読者によって異なります。

総括する：

  1. クラスにはペイロード メソッドが必要です
  2. パラメータを保存する/メンバーデータを返すだけでなく、少なくともいくつかの追加機能を持たないゲッター/セッターは役に立たない
  3. VBScript スクリプト コンテキスト (1 人のプログラマー、特定のタスクのための多くのアドホック スクリプト、再利用可能なコンポーネント/モジュールがほとんどない、OOP 機能の不完全なサポート) でも、「より良い」クラスでコードを整理します (init 関数、入力検証、集中型実装を使用)コア機能の) は良いことです。
于 2013-04-07T09:33:20.403 に答える
0

見た目も動作もほぼ同じです。ただし、最初にフィールドを使用し、次にプロパティを使用します。良い説明については、こちらをご覧くださいhttp://blogs.msdn.com/b/vbteam/archive/2009/09/04/properties-vs-fields-why-does-it-matter-jonathan-aneja.aspx

于 2013-04-07T06:12:06.337 に答える