Лучшее из «Совершенный код». Часть 1. Зачем нужно создавать методы

Сейчас я читаю одну очень интересную книгу Макконнелла под названием "Совершенный код", которая, кстати, является классикой жанра в области проектирования программ и написанию хорошего кода. Поскольку всё то, о чем говорится в книге, полностью подходит и для веб-разработки (чем я активно увлекаюсь), решил делиться интересными моментами, которые мне показались очень важными.

Сегодня же речь пойдет о том, зачем нужно создавать методы и в каких случаях.

Снижение сложности. Самая важная причина создания метода — снижение сложности программы. Создайте метод для сокрытия информации, чтобы о ней можно было не думать. Конечно, при написании метода думать о ней придется, но после этого вы сможете забыть о деталях и использовать метод, не зная о его внутренней работе. Другие причины создания методов — минимизация объема кода, облегчение сопровождения программы и снижение числа ошибок — также хороши, но без абстрагирующей силы методов сложные программы было бы невозможно охватить умом.
Одним из признаков того, что метод следует разделить, является глубокая вложенность внутренних циклов или условных операторов. Упростите такой метод, выделив вложенную часть в отдельный метод.

Предотвращение дублирования кода. Несомненно, самая популярная причина создания метода — желание избежать дублирования кода. Действительно, включение похожего кода в два метода указывает на ошибку декомпозиции. Уберите повторяющийся фрагмент из обоих методов, поместите его общую версию в базовый класс и создайте два специализированных метода в подклассах. Вы также можете выделить общий код в отдельный метод и вызвать его из двух первоначальных методов. В результате программа станет компактнее. Изменять ее станет проще, так как в случае чего вам нужно будет изменить только один метод. Код станет надежнее, потому что для его проверки нужно будет проанализировать только один фрагмент. Изменения будут реже приводить к ошибкам, поскольку вы не сможете по невнимательности внести в идентичные фрагменты программы чуть различающиеся изменения.

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

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

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

Упрощение сложных булевых проверок. Понимание сложных булевых проверок редко требуется для понимания пути выполнения программы. Поместив такую проверку в метод, вы сможете упростить код, потому что (1) детали проверки будут скрыты и (2) описательное имя метода позволит лучше охарактеризовать суть проверки.

Создание отдельного метода для проверки подчеркивает ее значимость. Это мотивирует программистов сделать детали проверки внутри метода более удобочитаемыми. В результате и основной путь выполнения кода, и сама проверка становятся более понятными. Упрощение булевых проверок является примером снижения сложности, которого мы уже не раз касались.

Повышение быстродействия. Методы позволяют выполнять оптимизацию кода в одном месте, а не в нескольких. Они облегчают профилирование кода, направленное на определение неэффективных фрагментов. Если код централизован в методе, его оптимизация повысит быстродействие всех фрагментов, в которых этот метод вызывается как непосредственно, так и косвенно, а реализация метода на более эффективном языке или с применением улучшенного алгоритма окажется более выгодной.

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

Автор: crows

Источник ^[1]