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