Дублирование кода и СТО по словам Роберта С. Мартина - PullRequest
Новая
       26

Дублирование кода и СТО по словам Роберта С. Мартина

1 голос
/ 06 июля 2019

Я читаю книгу «Чистая архитектура» Роберта Мартина. В примере для принципа единой ответственности он демонстрирует интерфейс для Сотрудника с тремя открытыми методами: calculatePay, reportHours и saveEmployee: 

class Employee {
public:
  float calculatePay();
  float reportHours();
  void saveEmployee();

private:
  float calculateRegularHours();
}

Он утверждает, что эти три метода не должны содержаться в одном классе, потому что они обслуживают разных участников: главный финансовый директор, главный операционный директор и главный технический директор. Затем он описывает последствия: если финансовый директор решит изменить метод расчета обычного рабочего времени, может случиться так, что случайно программист также изменит алгоритм расчета для COO, поскольку он полагается на один и тот же метод executeRegularHours.

Мой вопрос: как нам помогает соблюдение SRP? Даже если бы мы реализовали calculatePay и reportHours в двух разных классах, они все равно зависели бы от одного и того же метода calculateRegularHours, поэтому либо мы реализуем этот метод дважды (что было бы дублированием кода), либо мы должны принять риск того, что изменения в нем затронут обоих актеров.

Какой точки я не видел? Как бы вы справились с этой конкретной ситуацией?

Спасибо за ваши ответы!

1 Ответ

0 голосов
/ 09 июля 2019

либо мы реализуем этот метод дважды (что было бы дублированием кода)

Это похоже на дублирование кода, но это не так.Тот факт, что реализация для calculateRegularHours, которую используют calculatePay и reportHours, является одним и тем же, является просто случайностью.

Поскольку calculatePay и reportHours служат различным акторам, они будут меняться для разныхПричины в разное время.Таким образом, вполне вероятно, что один из этих актеров потребует изменения, которые другой актер не хочет.Итак, что касается этого запроса, что бы вы сделали?Я предполагаю, что вы разделите логику calculateRegularHours на 2 реализации.Один для calculatePay и один для reportHours.Но также вероятно, что вы забудете об этом и сломаете систему в месте, которое не имеет ничего общего с изменением, которое вы хотели сделать.Это делает систему хрупкой.

Роберт К. Мартин объясняет это в этом видео (39:26 - 43:00).

Полагаю, лучшим примером нарушения SRP является использование методов, которые обслуживают пользовательский интерфейс в бизнес-объекте, или даже представление SQL в виде.

Независимо от того, что вы делаете, у вас должны быть тесты, потому чтотесты могут показать вам, что вы сломали систему в совершенно другой области.И если это произойдет, вы должны переосмыслить дизайн и вспомнить SRP.

...