Структурирование классов

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 () для получения учетной записи. Что я на самом деле должен делать? Или это правильно? Статический класс подходит для этого лучше?

Я чувствую, что это становится очень загроможденным, и если оно становится больше, оно может быть неуправляемым с классами с похожими именами.

Как бы вы это структурировали? Поместите ли вы эти два метода из класса учетных записей в класс учетных записей?

Любое понимание здесь было бы так здорово.

Спасибо

Answer 1

Опыт часто является лучшим руководством, когда дело доходит до таких вопросов, потому что дизайн API все еще больше искусство, чем наука. В каждом классе, который вы разрабатываете, есть противоборствующие силы:

• С одной стороны, мы хотим, чтобы классы были связными инкапсуляции из связанных данных и поведения.
• С другой стороны, мы хотим придерживаться Принципа единой ответственности , чтобы избежать Объектов Бога .

В вашем конкретном случае может показаться, что все поведение относится к учетным записям, что будет аргументом для объединения всего этого в один класс.

Однако, исходя из моего личного опыта, я часто считаю полезным отделить создание объекта и время его жизни от реальных типов. Это позволяет Dependency Injection (DI) и DI Containers позаботиться о жизненном аспекте экземпляров, в то время как классы могут сосредоточиться на инкапсуляции данных и поведения.

В вашем конкретном случае класс Accounts во многом похож на Repository , который является типом (часто абстрактным), который мы используем для поиска экземпляров в базах данных или другом постоянном хранилище. Они часто лучше моделируются как отдельные типы, чем классы, которые они извлекают.

В заключение отметим, что в OOD вам не стоит беспокоиться о взрыве класса. Многие небольшие классы с различными обязанностями предпочтительнее.

Answer 2

Вы ищете шаблон Repository , который абстрагирует коллекцию объектов домена. Репозиторий для вашего домена может выглядеть так:

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));

Это помогает отделить определение операций от их фактической реализации. Это также позволяет вам выбирать, какой репозиторий вы предоставляете докладчику, также отделяя его от реализации.

Гибкость этого подхода предлагает больше свободы и позволяет лучше изменять, чем непосредственно создавать экземпляры зависимостей. Это называется Внедрение зависимостей .

Answer 3

В общем случае два метода будут идти в классе Account. В этом случае нет веской причины иметь два класса. Если вы используете методы 'Get', такие как GetAccountByID, их следует установить как static Это позволяет им вызываться без создания нового объекта учетной записи.

 public static Account GetAccountByID(int AccountID); 

тогда звонок:

Account editAccount = Account.GetAccountByID(234); 

Answer 4

Видение классов Account и Accounts меня немного беспокоит ... Я думаю, что Bank может быть лучшим названием для последнего.Таким образом, у вас есть банк, который предоставил доступ ко всем счетам или к одному конкретному счету.

Answer 5

На основании предоставленной вами информации я сделаю GetAllAccounts и GetAccountByID статическими и оставлю их в классе Accounts. Вы также можете создать статическую функцию для учетных записей, ответственных за создание и получение объектов учетной записи. У вашего класса должна быть только одна причина для изменения (принцип единой ответственности).

Answer 6

Как классы обычно структурированы в приложениях?

Плохо.

Что важнее, чем выяснить, что именно должно быть статичным и т. Д., Это убедиться, что все отношения между различными классами отражают отношения между реальными вещами, которые они моделируют.

Действительно ли "Счета" - это то, что есть в модели? Вам нужен класс для этого? Не могли бы вы иметь список учетных записей, а затем использовать операторы запросов на нем? Вместо метода, который получает учетную запись по его идентификатору, вы можете просто создать список и затем использовать accountList.First(x=>x.Id == 123). Возможно, это концепция, которую вам даже не нужно моделировать.