Принцип единой ответственности без дублирования кода (как это сделать?)

Question

Я задаю этот вопрос людям с передовыми знаниями в области архитектуры программного обеспечения.Я пытаюсь понять идею Единого принципа ответственности (SOLID), связанную с идеей устранения избыточности кода.Мое восприятие дублирования кода было то, что дублирование кода является чем-то неправильным, что должно быть исправлено и устранено.На самом деле я читаю «Чистую архитектуру» (Роберт К. Мартин), и мое восприятие изменилось, и я немного растерялся.

SRP делает акцент на актере, поэтому Роберт Мартин пишет: «Модуль должен отвечать за одного и только одного актера».В качестве примера Р. Мартин рассказывает о двух классах (модулях).Первый класс содержит метод «selectedPay ()», заданный отделом учета.Другой класс содержит метод «reportHours ()», указанный другим субъектом, отделом кадров.Обе функции имеют общий алгоритм (например, что-то вроде часового расчета).Естественным подходом было бы перенести общий алгоритм в другой класс и устранить дублирование кода.После этого обе функции будут вызывать алгоритм в новом классе.Представьте, что бухгалтерия должна изменить алгоритм (в новом классе).После изменения отдел кадров использует новый (недействительный) алгоритм.Существует проблема, и проблема вызвана нарушением SRP.Алгоритм класса (модуль) отвечает двум субъектам.С другой стороны, у нас было бы ненужное дублирование кода, что делает меня беспокойным.

Возможно, мой догматический подход к дублированию кода неверен, и нет ничего плохого в том, чтобы во многих местах использовать один и тот же код.Не так ли?Если я смотрю на это с другой точки зрения, то вижу, что существует множество алгоритмов / или просто частей кода, используемых несколькими клиентами (действующими лицами).И иногда используемый код необходимо изменить.Это что-то естественно для меня.Что было бы по-другому?Вот почему я не совсем понимаю, почему бы не поместить дублирование в другой класс.Другой пример с другим представлением: два класса с одной функцией в каждом, использующие общий алгоритм, но оба заданы бухгалтерией.Нет прерывания SRP, потому что существует только один актер с той же проблемой, все еще существует, потому что одно изменение может сделать недействительным другой класс.Это как-то очень неточно ...

Может быть, я не понимаю SRP и идею ...

Answer 1

Я сталкивался с такими же вопросами несколько семестров назад.Важность и основная концепция понимания SRP также заключается в понимании избыточного кода.

Сначала вы должны ознакомиться с концепцией избыточного кода.Давайте рассмотрим ОЧЕНЬ простой пример:

Actor1 использует класс A:

, который несет ответственность за ТОЛЬКО вычисление заданных входных данных от Actor1 и Actor1, а затем возвращает результат.

Actor2 будет использовать класс B:

, который отвечает за вычисление чего-то другого с учетом конкретных входных данных от Actor2, а затем возвращает результат.Однако при разработке класса мы понимаем, что часть вычислений содержит тот же код, что и класс A.

В этом примере класс B будет содержать избыточный код, если мы продолжим нашу разработку, поскольку он будет содержать дублированный код,который уже существует в классе A.

Решение:

В соответствии с SOLID (принцип Open / Closed) нам НЕ разрешено возвращаться и изменять класс A и разрешатькласс B, чтобы использовать это.Причина в том, что нам не разрешено удалять / изменять любой код, существующий в классе А. Причина в том, что мы можем отделить код от Actor1 или другого неизвестного актера.

Поэтому вместо этого мы пишем класс C, который расширяет классA, поэтому конкретные вычисления могут быть использованы через класс C, и, следовательно, могут быть использованы как классом B, так и любыми другими калибрами в будущем.

Надеюсь, это ответило на ваш вопрос!

Answer 2

SRP - это просто маркетинговый термин, который пытался продвинуть гораздо более старые (и гораздо более четко определенные) связные и соединительные концепции.Я бы предложил вернуться к этим терминам всякий раз, когда возникает вопрос о SRP.

Они ничего не говорят о дублировании кода как таковом, но они подразумевают, что «данные» должны всегда сопровождаться всеми связанными с ними данными. поведение .

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

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

Answer 3

Я хотел бы добавить: никакое проектное решение не должно быть статичным.

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

Answer 4

Как вы прочтете позже в книге:

Архитекторы часто попадают в ловушку - ловушку, основанную на их страхе дублирования.Дублирование, как правило, плохо в программном обеспечении.Нам не нравится дублированный код.Когда код действительно дублируется, мы, как профессионалы, обязаны его сократить и устранить.Но существуют разные виды дублирования.

Существует истинное дублирование , при котором каждое изменение одного экземпляра требует одинакового изменения для каждого дубликата этого экземпляра.Тогда есть ложное или случайное дублирование .Если два явно дублированных фрагмента кода развиваются по разным путям - если они изменяются с разной скоростью и по разным причинам - тогда они не являются истинными дубликатами .

Я думаю, что он объясняеточень хорошо, ваши сомнения.

Имея опыт и постоянное внимание, вы поймете, как использовать принцип SRP вместе с дублированием кода.

Мое личное мнение таково, что по мере того, как вы будете углубляться в шаблоны проектирования и архитектуру,вы столкнетесь с некоторыми философскими вопросами , на которые не могут (100%) ответить пользователи stackoverflow;)