После прочтения множества книг о хороших методах ООП (на Python, Java, Ruby, PHP и т. д.) и многих лет работы с объектами и попыток применить все концепции или правила, которые я узнал из них, я понял, что просто знаю, как сделать это, но я не могу вспомнить, почему я делаю это таким образом (или где я это прочитал).

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

ТВЕРДЫЕ принципы

SOLID — это мнемонический термин для пяти принципов проектирования в объектно-ориентированном программировании, предназначенный для того, чтобы сделать код более понятным, гибким и удобным в сопровождении. Дизайн является частью многих принципов, продвигаемых Робертом Мартином.

Единая ответственность

Класс должен иметь только одну обязанность.

Открыто закрыто

Сущности должны быть открыты для расширения, но закрыты для модификации.

Замена Лискова

Объекты в программе должны заменяться экземплярами их подтипов без изменения правильности этой программы.

Разделение интерфейса

Многие клиентские интерфейсы лучше, чем один интерфейс общего назначения.

Инверсия зависимости

Зависите от абстракций, а не от конкретики.

Чистый код

Общий

  • Должен быть 1 язык только в исходном файле.
  • Дублирование означает, что вы упускаете абстракцию, аналогичные алгоритмы следует решать с помощью шаблона TEMPLATE METHOD или STRATEGY.
  • Отделяйте общие понятия более высокого уровня от подробных понятий более низкого уровня.
  • Базовые классы ничего не должны знать о своих производных.
  • Слишком много информации: ограничьте то, что вы выставляете в интерфейсе своих классов и модулей. Чем меньше в классе методов, переменных, о которых знает функция, и экземпляров переменных в классе, тем лучше.
  • Локальные переменные должны быть объявлены выше их первого использования. Частные функции должны быть определены ниже их первого использования.
  • Может быть не более 1 оператора switch для данного типа выбора, случаи в этом операторе должны создавать объекты полиморфизма, которые занимают место другого такого оператора switch в остальной части системы.
  • Инкапсулируйте условные операторы.
  • Избегайте отрицательных условий.
  • Держите настраиваемые данные на высоком уровне.
  • Функции должны спускаться только на 1 уровень абстракции.

Правила имен

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

Правила функций

  • Должен быть маленьким.
  • Должен делать только одно.
  • Предпочитайте меньше аргументов.
  • Не должно быть побочного эффекта.
  • Не используйте флаговые аргументы. Разделить метод на несколько независимых методов, которые можно вызывать из клиента без флага.
  • Если в функции есть «try», это должно быть первое слово в функции, и после блоков catch/finally не должно быть ничего.
  • Следует соблюдать разделение команд и запросов.

Объекты и структуры данных

  • Следует соблюдать Закон Деметры (Принцип наименьшего знания).
  • Скрыть внутреннюю структуру.
  • Отдавайте предпочтение структурам данных.
  • Избегайте гибридных структур (наполовину объект и наполовину данные).
  • Базовый класс ничего не должен знать о своих производных.
  • Лучше иметь много функций, чем передавать некоторый код в функцию для выбора поведения.
  • Предпочитайте нестатические методы статическим методам.

параллелизм

  • Это отделение ЧТО от КОГДА.
  • Иногда может улучшить производительность.
  • Берет на себя некоторые накладные расходы.
  • Ошибки не повторяются.

Правила модульных тестов

Следует соблюдать три закона TDD:

  1. Не производственный код, пока не напишите провальный тест.
  2. Не писать больше модульного теста, чем достаточно для сбоя, а не компилировать — это сбой.
  3. Не писать больше производственного кода, чем достаточно для прохождения текущего неуспешного теста.