Question

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

我目前正在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类中的这两种方法放入帐户类？

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

由于

Answer 1

经验往往是这类问题的最佳指南，因为API设计更像是一门艺术而非科学。你设计的每个班级都有相反的力量：

一方面，我们希望类与相关的数据和行为具有内聚性封装。
另一方面，我们希望遵守Single Responsibility Principle以避免God Objects。

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

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

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

最后，在OOD你不应该担心课堂爆炸。许多具有不同职责的小班都是可取的。

Answer 2

您正在寻找Repository pattern，它抽象出一组域对象。您的域的存储库可能如下所示：

public interface IAccountRepository
{
    IList<Account> GetAll();

    Account GetById(int accountId);

    // Insert and delete, if they apply

    // Other account-specific queries and operations
}

演示者会声明对IAccountRepository的依赖：

public class EditAccountPresenter
{
    private readonly IEditAccountView _view;
    private readonly IAccountRepository _accounts;

    public EditAccountPresenter(IEditAccountView view, IAccountRepository accounts)
    {
        _view = view;
        _accounts = accounts;

        _view.DataBinding += OnDataBinding;
    }

    private void OnDataBinding(object sender, EventArgs e)
    {
        _view.Account = _accounts.GetById(234);
    }
}

接下来，在您创建演示者时，实现IAccountRepository但是您喜欢并将它们放在一起：

var dataContext = new AccountDataContext("...connection string...");

this.Presenter = new EditAccountPresenter(this, new AccountRepository(dataContext));

这有助于将操作的定义与其实际实现分离。它还允许您选择为演示者提供的存储库，并将其与实现分离。

与直接实例化依赖关系相比，这种方法的灵活性提供了更多的自由，并且可以更好地进行更改。这称为Dependency Injection模式。

Answer 3

根据您提供的信息，我会将GetAllAccounts和GetAccountByID设为静态，并将它们保留在Accounts类中。您还可以在负责创建和检索Account对象的Accounts上创建静态函数。你的班级应该只有一个改变的理由（单一责任原则）。

Answer 4

看到Account和Accounts课程让我感到困扰......我认为Bank可能是后者的更好名称。这样，您就拥有一个银行，可以访问所有帐户或单个特定帐户。

Answer 5

一般来说，这两种方法都会出现在Account类中。在这种情况下，没有令人信服的理由有两个班级。如果您正在使用GetAccountByID之类的“获取”方法，则应将这些方法设置为static。这样做可以在不实例化新帐户对象的情况下调用它们。

 public static Account GetAccountByID(int AccountID);

然后是电话：

Account editAccount = Account.GetAccountByID(234);

Answer 6

如何在应用程序中正常构建类？

Poorly.

比确定什么应该是静态的更重要的是确保各个类之间的所有关系反映他们建模的现实世界之间的关系。

“帐户”真的存在于模型中吗？你需要上课吗？你可以只有一个帐户列表，然后使用查询运算符吗？您可以只使用一个列表，然后使用accountList.First(x=>x.Id == 123)，而不是通过其ID获取帐户的方法。也许这是一个你甚至不需要首先建模的概念。

构建类

6 个答案: