0

例として、次のクラスを取り上げます。

public class Account
{
    public string Code { get; set; }
    public string Description { get; set; }
    public DateTime CreatedOn { get; private set; }  

    public void Create()
    {
        // Invoke with new Account({...}).Create();
    }

    //Or

    public static void Create(Account account)
    {
        // Invoke with Account.Create(new Account({...}));
    }
}

どちらCreate()のメソッドも同じことを行いますが、ご覧のとおり、呼び出し方が異なります。ある方法は他の方法よりも優れていますか? このようなコードを書くための用語はありますか?

4

4 に答える 4

2

この場合、静的メソッドを使用しないことをお勧めします。これは、多数のアカウントを作成する必要があり、すべてのアカウントに独自の異なるプロパティがあるためです。Create()しかし、コンストラクターを直接使用してアカウントを設定できるため、このメソッドは意味がないと思います。だからここに私がする方法があります：

public class Account
{
      public string Code { get; set; }
      public string Description { get; set; }
      public DateTime CreatedOn { get; private set; }  

      public Account()
      {
          Description = string.Empty;
          CreatedOn = DateTime.Now;
          //Code = ...
      }

      public Account(string Description)
      {
          this.Description = Description;
          CreatedOn = DateTime.Now;
          //Code = ...
      }
}

次に、アカウントを管理する別のクラスを作成します。

class AccountsManagement
{
      public List<Account> Accounts
      {
           get;
           set;
      } 

      public AccountsManagement()
      {
           Accounts = new List<Account>();
      }

      //...   

      public void Create()
      {
           Accounts.Add(new Account();
      }

      public void Create(string Description)
      {
           Accounts.Add(new Account(Description);
      }

      //Or

      public void AddAccount(Account account)
      {
           Accounts.Add(account);
      }

      //Find(), Delete()...
}

したがって、スピーチを続けることは悪い習慣ではありません静的メソッドを使用しますが、適切な場合にのみ使用する必要があります。

于 2012-06-04T07:30:04.347 に答える
1

一般的に、これが良い習慣か悪い習慣かはわかりません。ただし、あなたが与えた例では「悪い習慣」に傾いています(そして、型のインスタンスをその型で宣言された静的メソッドに渡す有用な理由を思いつくことはできません)。

確かにあなたの例では、（IMO）不明確なAPIを作成しています。かどうかはわかりません。

  • Account.Create は、アカウントのデータ ストレージ要求を発行することを目的としています (オブジェクト モデルの別の場所に確実に属する機能)。
  • いくつかのデフォルトのパラメーターセットを使用して Account のインスタンスを作成するためのある種の「便利な」方法です (おそらく Account のコンストラクターの方が優れているでしょう)。
  • コピーコンストラクターとして意味されます（この場合、コンストラクターである必要があります）
  • AccountFactory の安価な実装です (この場合、ファクトリを作成する必要があります!)

もう 1 つの考慮事項はテストです。静的メソッドは、それらを呼び出すものを単体テストするときに問題を引き起こす可能性があります。モックやスタブが簡単ではない可能性があるためです。

それらを除けば、技術的にこれについて本質的に「間違っている」ものは何もありません。ただし、他の方法で設計に影響します (たとえば、インスタンスではないため、インスタンス メンバーにアクセスできません)。

したがって、このアプローチは混乱を招く可能性があると思いますが、状況に完全に適している可能性もあります!

于 2012-06-04T07:23:17.107 に答える
1

メソッドの静的バージョンとインスタンス バージョンの両方が同じことを行う場合は、間違いなくインスタンス メソッド バージョンを使用します。いくつかの理由から:

  1. 書くコードが少ない。あなたはむしろ常に書いていますAccount.Create(accountObj);か、それとも単に書いていますaccountObj.Create();か？
  2. インテリセンス。カスタム オブジェクトがあり、作成したすべてのメソッドを思い出すことができない場合、入力accountObj.してドロップ ダウン メニューを取得し、それが使用するメソッドを確認するのに役立つことがよくあります。静的バージョンを使用すると、メソッドが表示されず、メソッドの使用方法/検索方法を覚えるのに数秒かかる場合がありますAccount.Create()。
  3. それは理にかなっています。カスタム オブジェクトの 1 つのインスタンスに対して機能するメソッドがある場合、それはインスタンス メソッドです。

Create()私の謙虚な意見では、インスタンスよりも静的バージョンを使用する唯一の理由は、メソッドがアカウント オブジェクトのプライベート メンバーにアクセスできないようにする必要がある場合です。

于 2012-06-04T07:34:01.967 に答える
0

Create などの静的メソッドを使用する唯一の理由は、デフォルトのコンストラクターを非公開にし、インスタンスの作成をヘルパー メソッドのみで制御したい場合です。
このような設計は、Microsoft 式ツリー フレームワークで実際に使用されます。ここでは、式クラスの静的メソッドを介してインスタンスを作成しますが、その間に抽象クラスのより複雑な階層もあります。

于 2012-06-04T07:38:23.697 に答える