c# – 构建类

发布时间：2020-12-15 23:54:26 所属栏目：百科来源：网络整理

导读：最终的问题是：如何在应用程序中正常构建类？我目前正在asp.net中编写测试银行应用程序例如：我有这两个类.一个代表一个帐户,另一个代表一个实用程序类(它有与帐户有关的东西,即获取帐户,更新帐户等) public Account { int ID; string Name; double Balanc

最终的问题是：如何在应用程序中正常构建类？

我目前正在asp.net中编写测试银行应用程序
例如：我有这两个类.一个代表一个帐户,另一个代表一个实用程序类(它有与帐户有关的东西,即获取帐户,更新帐户等)

public Account {
  int ID;
  string Name;
  double Balance;
}

public Accounts {
  public List<Account> GetAllAccounts();
  public Account GetAccountByID(int AccountID);
}

在我的表示层,每当我想要获得我正在使用的帐户时：

Account editAccount = new Accounts().GetAccountByID(234);

您可以看到我正在实例化一个新的Accounts()类来获取一个帐户.我该怎么做？或者这是正确的吗？静态类是否更适合这种需求？

我觉得这变得非常混乱,如果它变大,它可能无法控制具有相似名称的类.

你通常会如何构建这个？您是否将Accounts类中的这两种方法放入Account类中？

这里的任何见解都会非常棒.

谢谢

解决方法

对于这些问题,经验往往是最好的指导,因为API设计更像是一门艺术,而不是一门科学.你设计的每个班级都有相反的力量：

>一方面,我们希望类是相关数据和行为的内聚封装.
>另一方面,我们要坚持Single Responsibility Principle以避免God Objects.

在您的特定情况下,似乎所有行为都与Account相关,这可能是将其全部封装到一个类中的参数.

但是,根据我的个人经验,我经常发现将对象创建和生命周期与实际类型分开是很有价值的.这允许依赖注入(DI)和DI容器来处理实例的生命周期方面,而类可以专注于封装数据和行为.

在您的特定情况下,Accounts类看起来很像Repository,它是一种类型(通常是抽象的),我们用它来查找数据库或其他持久存储中的实例.它们通常更好地建模为与它们检索的类不同的类型.

最后,在OOD中你不应该担心类爆炸.许多具有不同职责的小班都是可取的.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!