Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 24 Рефакторинг 555 Метод использует больше элементов другого класса, чем своего собст' венного Это значит, что метод нужно переместить в другой класс и вызывать из старого класса. Элементарный тип данных перегружен Элементарные типы данных могут представлять бесконечное число сущностей реального мира. Если вы собираетесь представить распространенную сущность — скажем, денежную сумму — целочис# ленным или другим элементарным типом данных, подумайте: не создать ли вме# сто этого простой класс Money, чтобы компилятор мог выполнять контроль ти# пов объектов Money, дабы можно было проверять значения, присваиваемые этим объектам, и т. д. Если и Money, и Temperature будут представлены целыми числа# ми, компилятор не сможет предупредить вас об ошибочных операциях вида bank% Balance = recordLowTemperature. Класс имеет слишком ограниченную функциональность Иногда рефакто# ринг приводит к сокращению функциональности класса. Если класс не соответ# ствует своему званию, спросите себя, не удалить ли его вообще, распределив все аспекты его ответственности между другими классами. По цепи методов передаются бродячие данные Данные, передаваемые в ме# тод лишь затем, чтобы он передал их другому методу, называются «бродячими» (tramp data) (Page#Jones, 1988). Это не всегда плохо, но в любом случае спросите себя, согласуется ли передача конкретных данных с абстракцией, формируемой интерфейсом каждого из методов. Если с абстракциями интерфейсов порядок, с передачей данных тоже все в норме. Если нет, найдите способ, позволяющий улуч# шить согласованность интерфейса каждого метода. Объект'посредник ничего не делает Если роль класса сводится к перена# правлению вызовов методов в другие классы, подумайте, не устранить ли его и вызывать другие классы непосредственно. Один класс слишком много знает о другом классе Инкапсуляция (сокрытие информации) — наверное, самый эффективный способ улучшения интеллекту# альной управляемости программ и минимизации волновых эффектов изменений кода. Увидев, что один класс знает о другом больше, чем следует (это относится и к производным классам, знающим слишком много о своих предках), постарай# тесь сделать инкапсуляцию более строгой. Метод имеет неудачное имя Если методу присвоено плохое имя, измените определение метода, исправьте все его вызовы и перекомпилируйте программу. Какой бы трудной эта задача ни была сейчас, потом она станет еще труднее — поэтому, обнаружив проблему, устраните ее как можно быстрее. Данные'члены сделаны открытыми Мне кажется, что предоставление откры# того доступа к данным#членам не бывает разумным решением. Это стирает грань между интерфейсом и реализацией, неизбежно нарушает инкапсуляцию и огра# ничивает гибкость программы. Непременно подумайте над сокрытием открытых данных#членов при помощи методов доступа. Подкласс использует только малую долю методов своих предков Обыч# но такая ситуация возникает, когда подкласс создается потому, что базовый класс по чистой случайности содержит нужные ему методы, а не потому, что подкласс логически является потомком базового класса. Попробуйте достичь лучшей ин# 556 ЧАСТЬ V Усовершенствование кода капсуляции, изменив характер отношений между подклассом и базовым классом с «является» на «содержит»: преобразуйте базовый класс в данные#члены бывше# го подкласса и откройте доступ только к тем методам бывшего подкласса, кото# рые по#настоящему нужны. Сложный код объясняется при помощи комментариев В важности коммен# тариев трудно усомниться, но их не следует использовать для объяснения плохо# го кода. Старая мудрость гласит: «Не документируйте плохой код — перепишите его» (Kernighan and Plauger, 1978). Код содержит глобальные переменные При пересмотре фрагмента, в котором используются глобальные перемен# ные, изучите его получше. Возможно, за время, прошедшее с тех пор, как вы изучали этот фрагмент, вам пришел в го# лову способ устранения глобальных переменных. За это время вы уже забыли кое#какие аспекты кода — сейчас ис# пользование глобальных переменных может показаться вам довольно запутанным, чтобы вы сочли нужным изобретение более ясного подхода. Возможно, сейчас вы лучше представляете, как изолиро# вать глобальные переменные при помощи методов доступа и как пострадает про# грамма, если оставить все как есть. Соберитесь с силами и внесите в код выгод# ные изменения. Написание первоначального кода ушло в достаточно далекое прошлое, чтобы вы могли объективно отнестись к своей работе, но не настолько далекое, чтобы вы не смогли вспомнить все, что нужно для внесения правильных исправлений. Ранние ревизии кода — прекрасная возможность его улучшить. Перед вызовом метода выполняется подготовительный код (после вызова метода выполняется код «уборки») Подобный код должен вызывать у вас по# дозрение: Пример кода подготовки к вызову метода и кода уборки — плохой код (C++) Подготовительный код — дурной знак. WithdrawalTransaction withdrawal; withdrawal.SetCustomerId( customerId ); withdrawal.SetBalance( balance ); withdrawal.SetWithdrawalAmount( withdrawalAmount ); withdrawal.SetWithdrawalDate( withdrawalDate ); ProcessWithdrawal( withdrawal ); Код уборки — еще один дурной знак. customerId = withdrawal.GetCustomerId(); balance = withdrawal.GetBalance(); withdrawalAmount = withdrawal.GetWithdrawalAmount(); withdrawalDate = withdrawal.GetWithdrawalDate(); Похожий признак плохого кода — наличие специального конструктора, прини# мающего подмножество нормальных данных инициализации и нужного для на# писания чего#нибудь вроде: Перекрестная ссылка О глобаль- ных переменных см. раздел 13.3. О различиях между гло- бальными данными и данными класса см. подраздел «Ошибоч- ное представление о данных класса как о глобальных дан- ных» раздела 5.3. > > ГЛАВА 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. Возврат из метода сразу после получения ответа вместо установки воз' вращаемого значения внутри вложенных операторов ifthenelse Выход из метода сразу же после нахождения возвращаемого значения часто помогает об# легчить чтение кода и снизить вероятность ошибок. Альтернативный вариант — установка возвращаемого значения и следование к выходу из метода через зато# ры операторов — может оказаться более сложным. Замена условных операторов (особенно многочисленных блоков case) на вызов полиморфного метода Значительную часть логики, обычно включае# мой при структурном программировании в блоки case, можно реализовать с по# мощью наследования в виде полиморфных методов. Создание и использование «пустых» объектов вместо того, чтобы про' верять, равно ли значение null Иногда «пустой» объект должен иметь обоб# ГЛАВА 24 Рефакторинг 561 щенное поведение или обобщенные данные, например, определять неизвестно# го человека как «гражданина». В этом случае подумайте о перемещении ответствен# ности за обработку значений null из клиентского кода в класс, т. е. вместо того, чтобы проверять в клиентском коде класса Customer (заказчик), известно ли имя заказчика, и подставлять значение «гражданин», если оно неизвестно, определи# те неизвестного заказчика как «гражданина» прямо в классе Customer. Рефакторинг на уровне отдельных методов Извлечение метода из другого метода Превратите фрагмент метода в отдель# ный метод. Встраивание кода метода Если метод прост и понятен, можете не вызывать его, а встроить его код в программу. Преобразование объемного метода в класс Если метод слишком велик, по# пробуйте превратить его в класс и разбить на несколько методов. Иногда это по# вышает удобочитаемость кода. Замена сложного алгоритма на простой Этот вид рефакторинга пояснений не требует. Добавление параметра Если метод должен получать из вызывающего кода боль# ше информации, передавайте ее в форме дополнительного параметра. Удаление параметра Если метод не нуждается в каком#то параметре, удалите его. Отделение операций запроса данных от операций изменения данных Как правило, операции запроса данных не должны изменять состояние объекта. Если операция вроде GetTotals() (получение итоговой суммы) изменяет состояние объекта, разделите функциональность запроса и функциональность изменения со# стояния объекта, создав два отдельных метода. Объединение похожих методов путем их параметризации Два похожих метода могут различаться только используемой в них константой. Объедините их в один метод и передавайте в него нужное значение как параметр. Разделение метода, поведение которого зависит от полученных пара' метров Если метод выполняет разный код в зависимости от значения входно# го параметра, подумайте о разбиении метода на отдельные методы, которые можно было бы вызывать, не передавая этот входной параметр. Передача в метод целого объекта вместо отдельных полей Если вы пе# редаете в метод несколько значений одного объекта, подумайте о таком измене# нии интерфейса метода, чтобы он принимал сразу весь объект. Передача в метод отдельных полей вместо целого объекта Если вы со# здаете объект только затем, чтобы передать его в метод, подумайте о таком изме# нении метода, чтобы он принимал отдельные поля, а не весь объект. Инкапсуляция нисходящего приведения типов При возвращении объекта из метода обычно следует возвращать максимально определенный тип объекта. Это особенно справедливо для методов, возвращающих объекты#итераторы, наборы, элементы наборов и т. д. 562 ЧАСТЬ V Усовершенствование кода Рефакторинг реализации классов Замена объектов'значений на объекты'ссылки Если вы создаете и поддер# живаете много копий крупных или сложных объектов, измените подход так, что# бы существовал только один оригинал объекта (объект#значение), а в остальном коде использовались ссылки на этот объект (объекты#ссылки). Замена объектов'ссылок на объекты'значения Если вам приходится при# лагать усилия для обработки ссылок на небольшие или простые объекты, сделай# те все объекты#ссылки объектами#значениями. Замена виртуальных методов на инициализацию данных Если у вас есть набор подклассов, различающихся только возвращаемыми константами, не пере# определяйте методы#члены в подклассах, а инициализируйте базовый класс в подклассах соответствующими константами и включите в него обобщенный код, использующий эти константы. Изменение положения методов'членов или данных'членов в иерархии насле' дования Подумайте о внесении в иерархию наследования нескольких общих изменений. Следующие изменения обычно выполняются для устранения повто# рений кода в производных классах: перемещение метода в суперкласс; перемещение поля в суперкласс; перемещение тела конструктора в суперкласс. Другие изменения обычно вносятся с целью поддержки специализации в произ# водных классах: перемещение метода в производные классы; перемещение поля в производные классы; перемещение тела конструктора в производные классы. Перемещение специализированного кода в подкласс Если какой#то код класса используется только в подмножестве его экземпляров, переместите этот специа# лизированный код в отдельный подкласс. Объединение похожего кода и его перемещение в суперкласс Если несколько подклассов включают похожий код, объедините этот код и переместите его в су# перкласс. Рефакторинг интерфейсов классов Перемещение метода в другой класс Создайте в целевом классе новый ме# тод и переместите тело метода из исходного класса в целевой класс. После этого вы можете вызывать новый метод из старого. Разделение одного класса на несколько Если класс имеет более одной обла# сти ответственности, разбейте его на несколько классов, имеющих ясно опреде# ленные области ответственности. Удаление класса Если класс почти ничего не делает, переместите его код в другие, более связные классы и удалите его. Сокрытие делегата Иногда Класс A вызывает и Класс B, и Класс C, тогда как на самом деле A должен вызывать только B, а B — C. Спросите себя, какова пра# |