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

Так что я провел несколько разных «интервью», некоторые через WeChat , несколько через Google Forms , а остальные из внутренней ветки Google Chat .

Принцип единой ответственности

Результат супер захватывающий. Первый принцип — это «Принцип единой ответственности», или сокращенно SRP. Хотя есть и другие интерпретации, обычно SRP означает, что вы должны сделать свою функцию, класс или модуль как можно более простыми и последовательными.

Одним конкретным примером этого может быть то, что я использовал в ветке Google Chat:

… Я предлагаю им дать своим функциям осмысленные имена (относится к первому пункту) и посмотреть, должны ли они использовать такие союзы, как и/или, чтобы определить, что делает функция. Если это так, они должны разделить эту функцию…

Это также применимо к разным уровням вашего кода. Например, класс не должен делать две разные несвязанные вещи. Класс данных Personможет иметь name, addressи dob, но метода deliverбыло бы слишком много.

Например, ниже приведен пример, который я обсуждал в этой статье , Avatarкомпонент включает в себя Tooltipи покажет его, когда props.nameбудет предоставлен. Применяя SRP, вы можете разделить Tooltipсвязанный код с потребителем и убедиться, что он Avatarзаботится только о логике, связанной с аватаром.

Инкапсуляция

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

Я воспользуюсь примером из другой моей статьи здесь и покажу, как мы можем classлегко инкапсулировать эти открытые данные.

Обычно эти небольшие функции преобразования данных можно увидеть вместе с компонентами React, и по мере того, как внешний интерфейс использует эти данные, меняется (сопоставление abbr с полным именем или добавление логики if-else при необходимости), эти небольшие функции верхнего уровня стало трудно поддерживать. .

Тогда у нас может быть a classдля всех данных и функций преобразования. И у нас есть единственное место для изменения, если какая-либо логика для этого преобразования изменится. Также проще настроить тесты — вы определяете входные данные с некоторыми вариациями и проверяете выходные данные общедоступных методов из класса.

Не повторяйтесь

Номер три в списке СУХОЙ — не повторяйтесь. Мы все ненавидим повторять работу при кодировании, особенно когда нам приходится делать это вручную. Вообще говоря, правило трех применяется в большинстве случаев, то есть вы можете принять не более трех экземпляров дублирования.

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

Я обнаружил, что разные языки программирования предоставляют механизмы, которые упрощают или усложняют DRY. Например, в функциональных языках программирования вы можете передавать их так же, как и переменные, потому что функции являются первоклассными, что невозможно в чисто объектно-ориентированных языках.

И затем вы можете передать любую функцию, чтобы избежать дублирования, например:

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

Резюме

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

SRP гарантирует, что вы сосредоточитесь только на одной вещи и доведете ее до совершенства, а если все сделано правильно, тестируемость и компонуемость будут следующими. Хотя инкапсуляция помогает поместить связный контент, алгоритм, данные и логику в центральное место, она также облегчает понимание кода. И, наконец, DRY всегда сохраняет код в простом и лаконичном виде. Кроме того, вам не нужно беспокоиться о том, что вы забудете обновить другие места при изменении.

Использованная литература:

• Не повторяйтесь
• Прощай, чистый код
• Неправильная абстракция