Слишком много сбора?

Скажем, я отвлек структуру данных, такую ​​как список; должен ли этот новый объект выполнять все вычисления или просто предоставлять минимальные функции вычисления, а затем разрешить новый объект, такой как ReportGenerator, выполнять более крупномасштабные вычисления? Пример ниже:

ЭТА?

class WrappedCollection
{
  public double CalculateByYear(int year) {...}

  public double CalculateCumulativeByYear(int year) {...}

  public double CalculateTotal() {...}

  private IList<double> collection = new List<double>();
}

ИЛИ ЭТО?

class WrappedCalculation
{
  public double CalculateByYear(int year) {...}

  public double CalculateTotal() {...}

  private IList<double> collection = new List<double>();
}

class ReportGenerator
{
  public ReportGenerator(WrappedCollection collection) {...}

  public double TotalByYear(int year) {...}
  public double CumulativeTotalByYear(int year) {...}
  public double Total() {...}

  private WrappedCollection collection;
}

Это значительно упрощенная версия; однако я начинаю замечать, что в моем WrappedCollection мне нужны больше методов, и я чувствую, что нарушаю SRP. Класс WrappedCollection должен просто управлять тем, что я хочу (например, чей-то портфель выхода на пенсию), а отчет должен оставить другой класс, который выполняет все вычисления.

Кажется, я помню пример от дяди Боба Мартина или Мартина Фаулера, который показал, что все данные собираются дальше по иерархии в сами коллекции. Это, кажется, порождает более 1 ответственности.

В проекте сравниваются пенсионные портфели; поэтому я не считаю, что чей-то 401k должен дать мне все показатели, такие как совокупный вклад и т. д. Он должен просто дать мне текущую сумму и, возможно, взнос за определенный год по типу (например, работодатель и вклад сотрудников). Другой класс может составить список совокупных взносов. Да?

3 голоса | спросил keelerjr12 13 WedEurope/Moscow2017-12-13T19:15:57+03:00Europe/Moscow12bEurope/MoscowWed, 13 Dec 2017 19:15:57 +0300 2017, 19:15:57

2 ответа


0

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

Разделение двух способов, которые вы сделали, обеспечивает улучшение, но вы можете пойти еще дальше, указав интерфейс WrappedCalculation, скажем, IWrappedCalculation и код ReportGenerator в терминах этого интерфейса. Таким образом, вы сможете повторно использовать генератор отчетов, который вы написали для пенсионных портфелей, чтобы создавать отчеты для портфелей другого рода - например, портфели без пенсионного обеспечения или комбинации нескольких портфелей.

ответил dasblinkenlight 13 WedEurope/Moscow2017-12-13T20:05:20+03:00Europe/Moscow12bEurope/MoscowWed, 13 Dec 2017 20:05:20 +0300 2017, 20:05:20
3

Еще один разработчик, торпедированный принципами SOLID.

Ответственность не означает «делать только одно». Это означает, что «есть только одна причина для изменения» или, более конкретно, «Это место, чтобы пойти на внесение изменений в эту проблему». Наличие дополнительных методов в вашем классе не обязательно означает, что вы нарушаете SRP.

Репозиторий не имеет четырех обязанностей, поскольку он имеет методы создания, чтения, обновления и удаления. Он имеет только один доступ: .

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

ответил Robert Harvey 13 WedEurope/Moscow2017-12-13T19:48:49+03:00Europe/Moscow12bEurope/MoscowWed, 13 Dec 2017 19:48:49 +0300 2017, 19:48:49

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132