чудеса легкости

ФЛЕНОВ МИХАИЛ

Спецвыпуск: Хакер, номер #071, стр. 071-052-3

Как же мы любим объединять весь возможный код в одном методе! А ведь это грозит нам следующими проблемами:

- МЕТОД ОЧЕНЬ СЛОЖНО ЧИТАТЬ, ДАЖЕ ПРИ НАЛИЧИИ БОЛЬШОГО ЧИСЛА ПОДРОБНЫХ КОММЕНТАРИЕВ.

- КОД СЛОЖНЕЕ ИСПОЛЬЗОВАТЬ ПОВТОРНО. КОГДА МЕТОД ВЫПОЛНЯЕТ УЗКУЮ ЗАДАЧУ, ТО ЕГО МОЖНО ИСПОЛЬЗОВАТЬ В ДРУГОМ МЕСТЕ ПРОГРАММЫ, ГДЕ НЕОБХОДИМЫ ТЕ ЖЕ РАСЧЕТЫ. ЕСЛИ МЕТОД РЕШАЕТ НЕСКОЛЬКО ЗАДАЧ, ТО ВЕРОЯТНОСТЬ НЕОБХОДИМОСТИ ВЫПОЛНЕНИЯ ВСЕГО ТОГО ЖЕ В ДРУГОМ МЕСТЕ - НАМНОГО НИЖЕ.

- УСЛОЖНЯЕТСЯ ОТЛАДКА МЕТОДА, А В БОЛЬШИХ ПРОЕКТАХ И ОТЛАДКА ТЕСТИРОВАНИЯ ОТНИМАЕТ ДОСТАТОЧНО МНОГО ВРЕМЕНИ И СИЛ.

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

У данного совета могут быть противники, потому что избыточное количество вызовов методов – это снижение скорости. Да, вызов каждой процедуры требует лишних расходов, особенно если она получает много параметров. А если процедура за время выполнения программы будет вызываться сотни, а то и тысячи раз, то это уже серьезный удар по производительности. Да, лишние методы не нужны, но когда приходится выбирать между качеством кода и оптимизацией, я всегда выбираю первое и всем советую действовать так же.

[улучшение методов.]

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

В Delphi 2005 появилась достаточно интеллектуальная функция Refactor/Extract Method. В JBuilder та же функция спрятана в меню Edit/Extract Method. Чтобы воспользоваться ею, необходимо выделить отрывок кода, который нужно переместить в отдельный метод и выбрать указанный пункт меню. Перед нами открывается диалоговое окно, в котором достаточно ввести имя нового метода. Все остальное среда разработки сделает сама, а именно:

1 БУДЕТ СОЗДАН И КОРРЕКТНО ОБЪЯВЛЕН НОВЫЙ МЕТОД.

2 ВМЕСТО КОДА, КОТОРЫЙ МЫ ВЫДЕЛИЛИ, БУДЕТ ВСТАВЛЕН ВЫЗОВ ВНОВЬ СОЗДАННОГО МЕТОДА.

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

[размер метода.]

Многие авторитетные программисты считают, что методы должны быть максимально короткими, и если код не помещается на экран, то его необходимо разбить на несколько методов. Я бы не злоупотреблял этим правилом, потому что большое количество методов - тоже минус. Если метод решает одну и только одну задачу, то не стоит его делить на несколько, даже если он занимает два экрана. Просто купи монитор побольше :). Это, конечно же, шутка, - монитор побольше не нужен. Достаточно один раз отладить задачу и забыть про нее.