以此课程为例:
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()
方法都会做同样的事情,但正如您所看到的那样,它们的调用方式不同。是另一种更好的做法吗?是否有写这样的代码的术语?
答案 0 :(得分: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 = ...
}
}
Ant然后我会创建另一个类来管理帐户:
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()...
}
所以继续演讲这是不错的练习使用静态方法,但只有在适当的时候才能使用它们。
答案 1 :(得分:1)
一般来说,我不知道这是好事还是坏事。但是,在我给出的示例中,我倾向于“不良实践”(并且我无法想到将类型的实例传递给在该类型上声明的静态方法的任何有用的理由)。
当然,在您的示例中,您(IMO)正在创建一个不清楚的API。我不确定是否;
另一个考虑因素是测试 - 静态方法在单元测试任何调用它们的东西时会引入困难,因为它们可能不容易模拟或存根。
除此之外,从技术上讲,没有任何内在的“错误”。它会以其他方式影响您的设计(例如,不能访问实例成员,因为它不是实例)。
所以,我认为这种方法会导致一些混乱,但是,它也可能完全适合你的情况!
答案 2 :(得分:1)
如果方法的静态版本和实例版本都会做同样的事情,那么我肯定会使用实例方法版本。原因如下:
Account.Create(accountObj);
或accountObj.Create();
?accountObj.
并获取下拉菜单以查看它使用的方法。如果您使用静态版本,该方法将不会显示,您可能需要几秒钟的时间来记住如何使用/找到Account.Create()
方法。在我看来,在实例上使用静态版本的唯一原因是,如果您需要保持Create()
方法无法访问帐户对象的私有成员。
答案 3 :(得分:0)
我可以想到使用诸如Create这样的静态方法的唯一原因是你将你的默认构造函数设为私有,并希望仅通过ur helper方法控制实例的创建。
这样的设计实际上是由microsofts表达式树框架使用的,其中你通过表达式类的静态方法创建实例,但是它们之间也有一个更复杂的抽象类层次结构