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?
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.
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;
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 (eg; 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!
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:
Account.Create(accountObj);
or just accountObj.Create();
? 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. 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.
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
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.