Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 24 Рефакторинг 557 Пример кода подготовки к вызову метода и кода уборки — плохой код (C++) withdrawal = new WithdrawalTransaction( customerId, balance, withdrawalAmount, withdrawalDate ); withdrawal.ProcessWithdrawal(); delete withdrawal; Натолкнувшись на код, подготавливающий программу к вызову метода или вос- станавливающий ее боеспособность после вызова, спросите себя, формирует ли интерфейс метода адекватную абстракцию. В последнем примере список парамет- ров метода ProcessWithdrawal, возможно, следовало бы изменить так: Пример метода, не требующего ни подготовки, ни уборки, — хороший код (C++) ProcessWithdrawal( customerId, balance, withdrawalAmount, withdrawalDate ); Заметьте, что похожая проблема возникает и в обратном случае. Так, если у вас обычно есть объект WithdrawalTransaction, но в метод ProcessWithdrawal переда- ются только несколько значений объекта, вам следует подумать о рефакторинге интерфейса метода, чтобы он принимал объект WithdrawalTransaction, а не его отдельные поля: Пример кода, требующего нескольких вызовов методов (C++) ProcessWithdrawal( withdrawal.GetCustomerId(), withdrawal.GetBalance(), withdrawal.GetWithdrawalAmount(), withdrawal.GetWithdrawalDate() ); Каждый из этих подходов может быть как верным, так и неверным: все зависит от того, какую абстракцию формирует интерфейс метода ProcessWithdrawal(). Если абстракция подразумевает, что метод ожидает четыре отдельных элемента дан- ных, используйте один подход; если метод ожидает сразу весь объект Withdrawa- lTransaction, выберите другой. Программа содержит код, который может когда-нибудь понадобиться Программисты очень плохо угадывают, какая функциональность может потребо- ваться позднее. «Проектирование впрок» связано со многими предсказуемыми проблемами, описанными ниже. 쐽 Требования к коду, «проектируемому впрок», не разрабатываются в полном объеме, поэтому программист скорее всего не угадает эти будущие требова- ния. Код, «написанный в расчете на будущее», в итоге придется выбросить. 쐽 Если догадка программиста по поводу будущих требований близка к истине, он все же не сможет предвосхитить все их тонкости. Эти тонкости опроверг- нут исходные предпосылки проектирования, и «проект, разработанный в рас- чете на будущее», также придется выбросить. 쐽 Программисты, использующие код, который в свое время был «спроектирован впрок», не знают об этом или предполагают, что код лучше, чем есть на самом деле. Они думают, что этот код был написан, протестирован и подвергнут об- зору с той же тщательностью, что и остальной. Они могут потратить много времени на создание кода, использующего «спроектированное впрок», только для того, чтобы обнаружить в итоге, что «спроектированное впрок» на самом деле не работает. 558 ЧАСТЬ V Усовершенствование кода 쐽 Дополнительный код, «проектируемый впрок», создает дополнительную слож- ность, что приводит к дополнительному тестированию, исправлению дефек- тов и т. д. Результат — замедление работы над проектом. Мнение экспертов по этому поводу однозначно: если вы хотите наилучшим об- разом подготовиться к будущим требованиям, не пишите гипотетически нужный код, а уделите повышенное внимание ясности и понятности кода, который нужен прямо сейчас, чтобы будущие программисты знали, что он делает, чего не делает, и могли быстро и правильно изменить его (Fowler, 1999; Beck, 2000). Контрольный список: разумные причины выполнения рефакторинга Код повторяется. Метод слишком велик. Цикл слишком велик или слишком глубоко вложен в другие циклы. Класс имеет плохую связность. Интерфейс класса не формирует согласованную абстракцию. Метод принимает слишком много параметров. Отдельные части класса изменяются независимо от других частей. При изменении программы требуется параллельно изменять несколько классов. Вам приходится параллельно изменять несколько иерархий наследования. Вам приходится параллельно изменять несколько блоков case. Родственные элементы данных, используемые вместе, не организованы в классы. Метод использует больше элементов другого класса, чем своего собственного. Элементарный тип данных перегружен. Класс имеет слишком ограниченную функциональность. По цепи методов передаются бродячие данные. Объект-посредник ничего не делает. Один класс слишком много знает о другом классе. Метод имеет неудачное имя. Данные-члены сделаны открытыми. Подкласс использует только малую долю методов своих предков. Сложный код объясняется при помощи комментариев. Код содержит глобальные переменные. Перед вызовом метода выполняется подготовительный код (после вызова метода выполняется код «уборки»). Программа содержит код, который может когда-нибудь понадобиться. Когда не следует выполнять рефакторинг? Значение слова «рефакторинг» довольно размыто: так называют исправление де- фектов, реализацию новой функциональности, модификацию проекта — по сути любое изменение кода. Это неуместно. Целенаправленный процесс изменений может быть эффективной стратегией, обеспечивающей постепенное повышение качества программы при ее сопровождении и предотвращающей всем известную смертель- ную спираль энтропии ПО, но само по себе изменение достоинств не имеет. http://cc2e.com/2443 ГЛАВА 24 Рефакторинг 559 24.3. Отдельные виды рефакторинга Ниже вы найдете список видов рефакторинга, многие из которых я сформулиро- вал на основе более подробных описаний, приведенных в книге «Refactoring» (Fowler, 1999). Однако я не пытался сделать этот список исчерпывающим. В не- котором смысле каждый пример плохого и аналогичного хорошего кода в этой книге претендует на то, чтобы быть видом рефакторинга. Ради экономии места я привел только те виды рефакторинга, которые счел наиболее полезными. Рефакторинг на уровне данных Следующие виды рефакторинга связаны с использованием переменных и других видов данных. Замена магического числа на именованную константу Если вы использу- ете численный или строковый литерал, скажем, 3.14, замените его именованной константой, такой как PI. Присвоение переменной более ясного или информативного имени Если имя переменной неясно, присвойте ей лучшее имя. Конечно, этот же совет относится и к переименованию констант, классов и методов. Встраивание выражения в код Замените промежуточную переменную, кото- рой присваивается результат вычисления выражения, на само выражение. Замена выражения на вызов метода Этот вид рефакторинга обычно служит для устранения из кода повторяющихся выражений. Введение промежуточной переменной Присвойте результат вычисления вы- ражения промежуточной переменной, имя которой резюмирует суть выражения. Преобразование многоцелевой переменной в несколько одноцелевых пе- ременных Если переменная используется более чем с одной целью (к частым подозреваемым относятся такие переменные, как i, j, temp и x), создайте для каж- дой из целей отдельную переменную, выбрав для нее более определенное имя. Использование локальной переменной вместо параметра Если исключи- тельно входной параметр метода служит в качестве локальной переменной, по- думайте, не лучше ли создать для этого настоящую локальную переменную. Преобразование элементарного типа данных в класс Если элементарный тип данных нужно расширить дополнительными формами поведения (например, более строгим контролем типа) или дополнительными данными, преобразуйте его в класс и реализуйте нужное поведение. Это относится и к простым численным типам вроде Money и Temperature, и к перечислениям, таким как Color, Shape, Country или OutputType. Преобразование набора кодов в класс или перечисление В более старых про- граммах часто встречаются фрагменты вида: const int SCREEN = 0; const int PRINTER = 1; const int FILE = 2; Вместо определения таких отдельных констант лучше было бы создать класс Output- Type: это обеспечило бы вам достоинства более строгого контроля типов и по- 560 ЧАСТЬ V Усовершенствование кода зволило бы расширить семантику класса. Создание перечисления — иногда хо- рошая альтернатива созданию класса. Преобразование набора кодов в класс, имеющий производные классы Если разные элементы, ассоциированные с разными типами, могут иметь разное по- ведение, подумайте о создании базового класса для типа и производных классов для каждого кода типа. Так, для базового класса OutputType можно было бы создать подклассы Screen, Printer и File. Преобразование массива в класс Если элементами массива являются разные типы, создайте класс, включающий поля для каждого элемента массива. Инкапсуляция набора Если класс возвращает набор, наличие нескольких эк- земпляров набора может привести к проблемам с синхронизацией. Сделайте так, чтобы класс возвращал набор, допускающий только чтение, и создайте методы для добавления элементов в набор и их удаления. Замена традиционной записи на класс данных Создайте класс, содержащий члены записи (record). Это позволит централизовать проверку ошибок, слежение за персистентностью и выполнение других операций, касающихся записи. Рефакторинг на уровне отдельных операторов Декомпозиция логического выражения Упростите логическое выражение, вве- дя грамотно названные промежуточные переменные, документирующие суть вы- ражения. Вынесение сложного логического выражения в грамотно названную булеву функцию Если выражение достаточно сложное, этот вид рефакторинга повысит удо- бочитаемость кода. Если выражение используется более одного раза, он исключит необходимость внесения параллельных изменений и снизит вероятность ошибок. Консолидация фрагментов, повторяющихся в разных частях условного оператора Если в конце блока else содержится такой же фрагмент кода, что и в конце блока if, вынесите этот фрагмент за пределы оператора if-then-else. Использование оператора break или return вместо управляющей перемен- ной цикла Если для управления циклом используется такая переменная, как done, удалите ее и выполняйте выход из цикла при помощи оператора break или return. Возврат из метода сразу после получения ответа вместо установки воз- вращаемого значения внутри вложенных операторов if-then-else Выход из метода сразу же после нахождения возвращаемого значения часто помогает об- легчить чтение кода и снизить вероятность ошибок. Альтернативный вариант — установка возвращаемого значения и следование к выходу из метода через зато- ры операторов — может оказаться более сложным. Замена условных операторов (особенно многочисленных блоков case) на вызов полиморфного метода Значительную часть логики, обычно включае- мой при структурном программировании в блоки case, можно реализовать с по- мощью наследования в виде полиморфных методов. Создание и использование «пустых» объектов вместо того, чтобы про- верять, равно ли значение null Иногда «пустой» объект должен иметь обоб- ГЛАВА 24 Рефакторинг 561 щенное поведение или обобщенные данные, например, определять неизвестно- го человека как «гражданина». В этом случае подумайте о перемещении ответствен- ности за обработку значений null из клиентского кода в класс, т. е. вместо того, чтобы проверять в клиентском коде класса Customer (заказчик), известно ли имя заказчика, и подставлять значение «гражданин», если оно неизвестно, определи- те неизвестного заказчика как «гражданина» прямо в классе Customer. Рефакторинг на уровне отдельных методов Извлечение метода из другого метода Превратите фрагмент метода в отдель- ный метод. Встраивание кода метода Если метод прост и понятен, можете не вызывать его, а встроить его код в программу. Преобразование объемного метода в класс Если метод слишком велик, по- пробуйте превратить его в класс и разбить на несколько методов. Иногда это по- вышает удобочитаемость кода. Замена сложного алгоритма на простой Этот вид рефакторинга пояснений не требует. Добавление параметра Если метод должен получать из вызывающего кода боль- ше информации, передавайте ее в форме дополнительного параметра. Удаление параметра Если метод не нуждается в каком-то параметре, удалите его. Отделение операций запроса данных от операций изменения данных Как правило, операции запроса данных не должны изменять состояние объекта. Если операция вроде GetTotals() (получение итоговой суммы) изменяет состояние объекта, разделите функциональность запроса и функциональность изменения со- стояния объекта, создав два отдельных метода. Объединение похожих методов путем их параметризации Два похожих метода могут различаться только используемой в них константой. Объедините их в один метод и передавайте в него нужное значение как параметр. Разделение метода, поведение которого зависит от полученных пара- метров Если метод выполняет разный код в зависимости от значения входно- го параметра, подумайте о разбиении метода на отдельные методы, которые можно было бы вызывать, не передавая этот входной параметр. Передача в метод целого объекта вместо отдельных полей Если вы пе- редаете в метод несколько значений одного объекта, подумайте о таком измене- нии интерфейса метода, чтобы он принимал сразу весь объект. Передача в метод отдельных полей вместо целого объекта Если вы со- здаете объект только затем, чтобы передать его в метод, подумайте о таком изме- нении метода, чтобы он принимал отдельные поля, а не весь объект. Инкапсуляция нисходящего приведения типов При возвращении объекта из метода обычно следует возвращать максимально определенный тип объекта. Это особенно справедливо для методов, возвращающих объекты-итераторы, наборы, элементы наборов и т. д. 562 ЧАСТЬ V Усовершенствование кода Рефакторинг реализации классов Замена объектов-значений на объекты-ссылки Если вы создаете и поддер- живаете много копий крупных или сложных объектов, измените подход так, что- бы существовал только один оригинал объекта (объект-значение), а в остальном коде использовались ссылки на этот объект (объекты-ссылки). Замена объектов-ссылок на объекты-значения Если вам приходится при- лагать усилия для обработки ссылок на небольшие или простые объекты, сделай- те все объекты-ссылки объектами-значениями. Замена виртуальных методов на инициализацию данных Если у вас есть набор подклассов, различающихся только возвращаемыми константами, не пере- определяйте методы-члены в подклассах, а инициализируйте базовый класс в подклассах соответствующими константами и включите в него обобщенный код, использующий эти константы. Изменение положения методов-членов или данных-членов в иерархии насле- дования Подумайте о внесении в иерархию наследования нескольких общих изменений. Следующие изменения обычно выполняются для устранения повто- рений кода в производных классах: 쐽 перемещение метода в суперкласс; 쐽 перемещение поля в суперкласс; 쐽 перемещение тела конструктора в суперкласс. Другие изменения обычно вносятся с целью поддержки специализации в произ- водных классах: 쐽 перемещение метода в производные классы; 쐽 перемещение поля в производные классы; 쐽 перемещение тела конструктора в производные классы. Перемещение специализированного кода в подкласс Если какой-то код класса используется только в подмножестве его экземпляров, переместите этот специа- лизированный код в отдельный подкласс. Объединение похожего кода и его перемещение в суперкласс Если несколько подклассов включают похожий код, объедините этот код и переместите его в су- перкласс. Рефакторинг интерфейсов классов Перемещение метода в другой класс Создайте в целевом классе новый ме- тод и переместите тело метода из исходного класса в целевой класс. После этого вы можете вызывать новый метод из старого. Разделение одного класса на несколько Если класс имеет более одной обла- сти ответственности, разбейте его на несколько классов, имеющих ясно опреде- ленные области ответственности. Удаление класса Если класс почти ничего не делает, переместите его код в другие, более связные классы и удалите его. Сокрытие делегата Иногда Класс A вызывает и Класс B, и Класс C, тогда как на самом деле A должен вызывать только B, а B — C. Спросите себя, какова пра- ГЛАВА 24 Рефакторинг 563 вильная абстракция взаимодействия Класса A с Классом B. Если за вызов C дол- жен отвечать B, внесите нужные изменения. Удаление посредника Если Класс A вызывает Класс B, а Класс B вызывает Класс C, подумайте, не лучше ли вызывать C непосредственно из A. Целесообразность делегирования полномочий Классу B зависит от того, улучшит ли это целостность его интерфейса или ухудшит. Замена наследования на делегирование Если из одного класса нужно исполь- зовать другой класс, но вы хотите получить больший контроль над интерфейсом второго класса, сделайте суперкласс полем бывшего подкласса и создайте для доступа к нему набор открытых методов, формирующих связную абстракцию. Замена делегирования на наследование Если класс предоставляет доступ ко всем открытым методам класса-делегата (класса-члена), выполните наследование от класса-делегата, а не просто используйте его. Создание внешнего метода Если в класс нужно включить дополнительный ме- тод, но изменять класс нельзя, вы можете создать нужный метод в клиентском классе. Создание класса-расширения Если в класс нужно включить несколько допол- нительных методов, но изменять класс нельзя, вы можете создать новый класс, объединяющий функциональность неизменяемого класса с дополнительной функ- циональностью. Для этого вы можете или выполнить наследование от исходного класса и добавить новые методы в подклассы, или заключить класс в оболочку, предоставив доступ к нужным методам. Инкапсуляция открытой переменной-члена Если данные-члены открыты, сделайте их закрытыми и реализуйте доступ к ним при помощи методов. Удаление методов установки значений неизменяемых полей Если поле предполагается устанавливать во время создания объекта и не изменять впослед- ствии, инициализируйте поле в конструкторе объекта и не создавайте вводящий в заблуждение метод Set(). Сокрытие методов, которые не следует вызывать извне класса Если без метода интерфейс класса будет более согласованным, скройте метод. Инкапсуляция неиспользуемых методов Если обычно вы используете толь- ко часть интерфейса класса, создайте новый интерфейс, предоставляющий до- ступ только к необходимым методам. Убедитесь в том, что новый интерфейс фор- мирует согласованную абстракцию. Объединение суперкласса и подкласса, имеющих очень похожую реали- зацию Если степень специализации подкласса невысока, объедините его с су- перклассом. Рефакторинг на уровне системы Создание эталонного источника данных, которые вы не можете конт- ролировать Иногда какие-то данные трудно согласованно использовать из дру- гих объектов, которым нужны эти данные. В качестве примера можно привести данные элемента управления с GUI-интерфейсом. В этом случае вы можете создать 564 ЧАСТЬ V Усовершенствование кода класс, воспроизводящий данные элемента управления, и рассматривать этот класс как эталонный источник данных и для элемента управления, и для другого кода. Изменение однонаправленной связи между классами на двунаправленную Если два класса должны использовать возможности друг друга, но только один класс знает о другом классе, измените классы так, чтобы они оба знали друг о друге. Изменение двунаправленной связи между классами на однонаправленную Если два класса известны друг другу, но на самом деле только один класс должен знать о другом, измените характер связи между классами. Предоставление фабричного метода вместо простого конструктора Ис- пользуйте фабричный метод, если вам нужно создавать объекты на основе кода типа или если вы хотите работать с объектами-ссылками, а не объектами-значениями. Замена кодов ошибок на исключения или наоборот Убедитесь, что вы ис- пользуете стандартный подход к обработке ошибок, основанный на той или иной стратегии. Контрольный список: виды рефакторинга Рефакторинг на уровне данных Замена магического числа на именованную константу. Присвоение переменной более ясного или информативного имени. Встраивание выражения в код. Замена выражения на вызов метода. Введение промежуточной переменной. Преобразование многоцелевой переменной в несколько одноцелевых пере- менных. Использование локальной переменной вместо параметра. Преобразование элементарного типа данных в класс. Преобразование набора кодов в класс или перечисление. Преобразование набора кодов в класс, имеющий производные классы. Преобразование массива в класс. Инкапсуляция набора. Замена традиционной записи на класс данных. Рефакторинг на уровне отдельных операторов Декомпозиция логического выражения. Вынесение сложного логического выражения в грамотно названную булеву функцию. Консолидация фрагментов, повторяющихся в разных частях условного опе- ратора. Использование оператора break / return вместо управляющей переменной цикла. Возврат из метода сразу после получения ответа вместо установки возвра- щаемого значения внутри вложенных операторов if-then-else. Замена условных операторов (особенно многочисленных блоков case) на вызов полиморфного метода. Создание и использование «пустых» объектов вместо проверки того, равно ли значение null. http://cc2e.com/2450 |