Процедурный код (код, использующий структуры данных) позволяет легко добавлять новые функции без изменения существующих структур данных.
ООП-код упрощает добавление новых классов без изменения существующих функций.
Процедурный код усложняет добавление новых структур данных, так как требуется изменение всех функций.
ООП-код усложняет добавление новых функций, так как требуется изменение всех классов.
Данные необязательно представляются в виде объектов.
Закон Деметры – модуль не должен знать внутреннее устройство объектов, с которыми работает.
Метод f класса С должен ограничиваться вызовом методов следующих объектов: С; объекты, созданные f; объекты, переданные f в качестве аргумента; объекты, хранящиеся в переменной экземпляра С.
Метод не должен вызывать методы объектов, возвращаемых любыми из разрешенных функций.
Не использовать цепочки вызовов (разделять).
Не используются гибриды объектов и структур данных.
Разные уровни детализации не смешиваются.
Объекты передачи данных – Data transfer object – классы с открытыми переменными без функций используются для преобразования низкоуровневых данных, получаемых из базы, в объекты кода приложения.
Bean – компоненты из приватных переменных, операции с которыми осуществляются при помощи методов чтения и записи, преимуществ не имеют.
Активные записи – active records – структуры данных с открытыми переменными, а также с навигационными методами – это структуры данных и бизнес-логику не содержат.
Обработка ошибок не заслоняет логику программы.
Ошибки обрабатываются стильно и элегантно.
Используются исключения вместо кодов ошибок.
Начинать с написания команды try-catch-finally для кода, способного вызывать исключение.
Тип исключения сужается до реально инициируемого.
Блоки try должны напоминать транзакции.
Использовать непроверямые исключения.
С исключениями передавать содержательные сообщения об ошибках.
Из сведений об исключении должно быть понятно, с какой целью выполнялась операция.
Классы исключений определены в контексте потребностей вызывающей стороны.
Инкапсулированы вызовы сторонних API.
Для обработки особых случаев использовать паттерн особый случай.
Вместо null выдается исключение или особый случай.
Для API, возвращающего null, – делать обертки.
Не возвращать null из методов.
Не передавать null при вызове методов.
Запрещать передачу null по умолчанию.
Чистый код должен быть надежным.
Вместо приведения типа контейнера лучше использовать параметризованные контейнеры.
Ограничить передачу граничных интерфейсов по платформе (можно инкапсулировать).
Для стороннего кода писать тесты.
Сторонний код тестировать в рамках понимания его работы.
Конструкторы по умолчанию должны иметь конфигурацию.
Писать учебные тесты, граничные тесты.
Можно заранее определять интерфейсы, затем писать паттерн-адаптер к готовым.
Для граничного кода необходимо четкое разделение сторон и тесты, определяющие ожидания пользователя.
Количество обращений к границам стороннего кода сводится к минимуму.
Законы TDD:
– не пишите код продукта, пока не напишете отказной модульный тест;
– не пишите модульный тест в объеме большем, чем необходимо для отказа (невозможность компиляции является отказом);
– не пишите код продукта в объеме большем, чем необходимо для прохождения текущего отказного теста.
Тесты не уступают в качестве коду продукта.
Тесты развиваются вместе с продуктом.
Модульные тесты обеспечивают гибкость, удобство сопровождения и возможность повторного использования кода.
Без тестов любое изменение становится потенциальной ошибкой.
Некачественные тесты приводят к некачественному коду продукта.