Is it bad practice to only create static methods that take instances of that type

Question

Take this class for example:

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({...}));
    }
}

Both Create() methods will both do the same thing, but as you can see they are invoked differently. Is one better practice over the other? Is there a term for writing code like this?

How does it work with a `void` return type? What is the effect? — leppie, Jun 04 '12 at 07:07
Is your static function just a wrapper for calling the non-static function? — brianestey, Jun 04 '12 at 07:08
This is called function overloading in terms of oops. If you want to do some things on object creation then use constructors with different parameters. — Romil Kumar Jain, Jun 04 '12 at 07:12
@Nick I would say adds a layer of confusion, which could be considered bad. I don't really understand your intention behind such a method structure. If you can give some ideas why you laid out your code this way, it might make the question a bit clearer. — brianestey, Jun 04 '12 at 08:27

Omar · Answer 1 · 2012-06-04T07:36:58.743

In this case I reccomend you don't use a static method, because you should create a lot of accounts and every account will have its own different properties. But I think that the method Create() has no sense, beacuse you can use directly the constructor to set the account. So here is how I would do:

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 = ...
      }
}

Ant then I would create another class to manage the accounts:

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()...
}

So continuing the speech it isn't bad practice use static methods, but they should be used only when opportune.

score 1 · Accepted Answer · answered Jun 04 '12 at 07:23

In general, I don't know that this is either good or bad practice. However, I would lean towards 'bad practice' in the example you have given (and I can't off hand think of any useful reasons to pass an instance of a type to a static method declared on that type).

Certainly in your example, you are (IMO) creating an unclear API. I'm not sure whether;

Account.Create is meant to issue data storage requests for an account (functionality that certainly belongs elsewhere in your object model)
is some sort of 'convenience' method for creating an instance of Account using some default set of parameters (which would arguably be better in a constructor of Account)
is meant as a copy constructor (in which case, it should be a constructor)
is a cheap implementation of an AccountFactory (in which case you should make a factory!)

Another consideration is testing - static methods can introduce difficulties when unit testing anything that calls them, as they may not be easy to mock or stub.

Apart from those, there is nothing inherently 'wrong' about this, technically. It affects your design in other ways though (e.g; no access to instance members as it is not an instance).

So, I think this approach can lead to some confusion, however, it might also be entirely appropriate for your situation!

score 1 · Answer 3 · answered Jun 04 '12 at 07:34

If both the static and instance versions of the method will do the same thing then I would definitely use the instance method version. For a few reasons:

Less code to write. Would you rather constantly write Account.Create(accountObj); or just accountObj.Create(); ?
Intellisense. When I have a custom object and I can't remember all the methods I've made on it, it often helps me to type accountObj. and get the drop down menu to see what methods it uses. If you use the static version, the method will not show up and it might take you a few seconds to remember how to use/find the Account.Create() method.
It just makes sense. If you have a method that works on a single instance of a custom object, it is an instance method.

The only reason, in my humble opinion, to use the static version over the instance is if you need keep the Create() method from having access to private members of the account object.

score 0 · Answer 4 · answered Jun 04 '12 at 07:38

The only reason i can think of to use such static methods as your Create, is the cases where you make ur default constructor private, and wish to control the creation of instances only via ur helper method.
Such design is actually used by microsofts expression trees framework, where u create the instances via static methods of th expression class, however they also have a more complicated hierarchy of abstract classes in between

Is it bad practice to only create static methods that take instances of that type

4 Answers4