vchernoivan@gmail.com http://chernoivan.ru/oop/ Как писать «хороший» код? Code Smells …или что такое «хорошо» и что такое «плохо» Ваш код читают люди
Ваша цель — быть понятными
Комментарии • Отсутствие в интерфейсах классов и модулей – Действительно ли все понятно только по сигнатуре? – Любые значения параметров допустимы и равнозначны? – Любые возвращаемые значения допустимы и равнозначны ? – Нет никаких специальных случаев и исключительных ситуаций? Комментарии Комментарии Комментарии Комментарии • Наличие в реализациях – Ваши комментарии отвечают на вопросы «что?» и «как?»? – Ваши комментарии поясняют что-то неочевидное из прочтения на C++? – Можно ли переписать Ваш код так, чтобы комментарии были не нужны? Комментарии Дублирующийся код Дублирующийся код Решение: определить функцию (метод) Дублирующийся код
Необязательно код дублируется дословно.
Часто бывает, что одну и ту же задачу решают
несколькими похожими способами.
Нужно выбрать один!
Длинный метод Длинная функция (метод) Длинный кусок кода сложнее для чтения и понимания (при прочих равных).
Решение: декомпозиция • Самое простое — декомпозиция на понятные по смыслу операции (ф-и и методы) и наименование их соответствующим образом • Возможны и более сложные декомпозиции, такие, как мы применили в случае разбиения на команды Сложные логические структуры (if/else switch/case for/while)
● Большое количество ● Большая вложенность ● А ТАКЖЕ ОПЕРАТОР goto! ● Решение: все то же самое — декомпозиция Длинный список параметров одержимость примитивами Длинный список параметров • Скорее всего либо неправильно декомпозирован метод, либо неправильно выбраны параметры • Решение – Разделить метод на несколько с меньшим количеством параметров – Объединить параметры в сущность более высокого уровня • Одержимость примитивами или связки данных – Если примитивные данные появляются все время «в связке», вероятно, они принадлежат друг другу? – Не используйте примитивные типы данных как «босяцкую» замену классам. Если данные сложны, напишите класс Чрезмерное использование литеральных констант
Commands. Чрезмерное использование литеральных констант
Или разного рода «Волшебных чисел», «Волшебных
строк» и т. п. • Сложно отлавливать опечатки • Ухудшает читаемость текста • Затрудняет перевод
• Решение: используйте именованные константы
Идентификаторы
• Чрезмерно длинные • Чрезмерно короткие • И то и другое затрудняет читаемость кода. Идентификаторы должны быть с одной стороны, читаемы, с другой – понятными. • Имена объектов должны объяснять, для чего нужны объекты Идентификаторы Принципы ООП Принципы здравого смысла Don't-Repeat Yourself (не повторяйся)
• Любая информация (часть знания) должна иметь
единственный, авторитетный и непротиворечивый источник в рамках системы
• Этот принцип включает в себя дублирование кода,
использование именованных констант вместо литералов, но не ограничивается ими. – Например, код, документация и диаграммы это три разных представления модели. DRY требует, чтобы все три представления имели один и тот же источник Keep It Simple Stupid (не усложняй) • Архитектура системы должна быть максимально простой
• Защита от желания разработчиков применить более
сложные конструкции, чем необходимо
• ВАЖНО: предполагается, что система работает и
остается объектно-ориентированной вне зависимости от сложности архитектуры You Ain’t Gonna Need It (тебе это не понадобится)
• Не нужно реализовывать функциональность,
которая “понадобится в будущем”
• Защита от желания разработчиков реализовать
функционал, который кажется им важным, но не имеет достаточного бизнес значения Самый лучший способ позаботиться о будущем — не думать о нем слишком много
интерфейсов, нежели один «толстый», который отвечает за все ISP: МФУ Xerox ISP: МФУ Xerox ISP: System.Collections.IList ISP: System.Collections.Generic.IList ISP Dependency Inversion Principle (принцип инверсии зависимости)
• Классы верхних уровней не должны зависеть от
классов нижних уровней. Оба типа классов должны зависеть от интерфейсов.
• Абстракции не должны зависеть от деталей.
Детали должны зависеть от абстракций DIP: Векторная графика
? DIP: Векторная графика Liskov Substitution Principle (Принцип подстановки Лисков) • Объект базового типа можно заменить объектом производного типа без ущерба для правильности работы программы • Наследуемый класс не может иметь более сильных пред-условий или более слабых пост- условий. • Наследуемый класс не может – Требовать большего – Обещать меньшее LSP: Прямоугольник и квадрат LSP: Прямоугольник и квадрат LSP: System.Collections.IList Спасибо за внимание. Вопросы?
