|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Рефакторинг программного кодаСтр 1 из 2Следующая ⇒
Рефакторинг программного кода
Цель работы: научиться выполнять реорганизацию программного кода на основании шаблонов рефакторинга.
Ход выполнения работы
Требования к содержанию работы
Теоретические сведения
Признаки плохо организованного кода Это не набор четких правил, а описание мест, на которые надо обращать внимание при рефакторинге. Дублирующийся код Если вы видите одинаковые структуры кода в нескольких местах, то вы можете быть уверены, что эта программа будет лучше, если вы сможете их унифицировать. В простейших случаях вам поможет Extract Method. При работе с наследованием используйте Pull Up Field. Если код похож, но не в точности, надо применить Extract Method, а затем Form Template Method. Если методы делают одно и то же разными способами, выберите один из них и используйте Substitute Algorithm. Если у вас есть дублирующийся код в несвязанных классах, подумайте о возможности Extract Class. Длинный Метод Из объектных программ, дольше всего живут программы с короткими методами. Чем длиннее процедура, тем труднее ее понять. Если у вас есть хорошее название для метода, то вам не нужно смотреть его тело. Мы следуем эвристике: как только мы чувствуем, что надо написать комментарий, мы вместо этого пишем метод. В 99% случаев для того, чтобы сократить метод, вам достаточно будет применить Extract Method. Локальные переменные и параметры могут препятствовать вам, так что, возможно, вам понадобится Replace Temp With Query, Introduce Parameter Object и Preserve Whole Object. Кроме комментариев, циклы и условия также являются хорошими знаками. Используйте Decompose Conditional для условий, а для циклов - выносите тело цикла в отдельный метод. Большой класс Когда класс делает слишком много всего, у него обычно слишком много полей. Можно использовать Extract Class или Extract Subclass, чтобы выделить некоторые переменные. При определении того, что выносить, обращайте внимание на общность в названии переменных, а также на то использует ли класс их все одновременно. Кроме того, класс, в котором слишком много кода, также является рассадником дублирования и хаоса. Здесь также применяйте Extract Class или Extract Subclass. Если ваш большой класс - это GUI класс, то попытайтесь отделить поведение от данных. Вам может понадобиться Duplicate Observed Data. Длинный список параметров Это пережиток процедурного программирования. В объектном мире всегда найдется объект, которому можно задать вопрос и получить все нужные ответы. Используйте Replace Parameter with Method, Preserve Whole Object и Introduce Parameter Object. Расходящееся изменение Расходящееся изменение - это когда один класс подвержен различным изменениям. Мы структурируем наше ПО, чтобы было легче его изменять. Если мы хотим что-то изменить, мы ищем единственное место, где мы можем сделать изменение. Если мы не можем этого сделать - мы ощущаем плохой запах. Вы можете смотреть на класс и думать: " вот эти три метода я меняю каждый раз когда подключаю новую БД, а эти четыре - при добавлении финансового инструмента". Для того, чтобы привести это в порядок, находите все, что меняется в данном частном случае и используйте Extract Class. Хирургия дробовиком Это похоже на расходящееся изменение, только наоборот. Каждый раз, когда вам надо сделать подобное изменение, вы делаете кучу мелких изменений в различных классах. Это часто приводит к ошибкам. Используйте Move Method и Move Field для того чтобы вынести все изменения в один класс. Если никакой класс не выглядит хорошим кандидатом, создайте новый класс. Используйте Inline Class, если необходимо. Расходящееся изменение - это когда один класс подвержен различным изменениям, тогда как хирургия дробовиком - это когда одно изменение затрагивает несколько классов. Зависть по функции Цель наличия объектов в программе - объединить данные и методы, их использующие. Типичный дурной запах - когда метод выглядит более заинтересованным в данных другого объекта, нежели своих. Просто используйте Move Method, чтобы перенести его туда, где он должен быть. Если только часть метода страдает завистью, используйте сначала Extract Method. В случае, когда метод использует данные от нескольких объектов, поместите его к объекту, в котором он заинтересован больше всего. Используйте Extract Method для изоляции зависимостей. Использование некоторых сложных шаблонов, таких как Strategy и Visitor, нарушает эти правила. Общая рекомендация - всегда соблюдать баланс между сложностью и необходимой гибкостью. Группы данных Если вы видите, что элементы данных всегда путешествуют вместе, объедините их в один объект. Используйте Extract Class для полей, Preserve Whole Object и Introduce Parameter Object для параметров методов. Хороший метод проверки: если вы удалите один из элементов данных, будут ли остальные иметь смысл? Если да, то здесь должен быть рожден объект. Одержимость примитивами Начинающие объектные программисты обычно избегают использовать маленькие объекты для маленьких задач, таких как валюта, диапазоны, специальные строки для телефонных номеров и т.п. Вы можете выйти из пещер в цивилизованный мир объектов с помощью Replace Data Value with Object, Replace Array with Object, если это код типа, то используйте Replace Type Code with Class, Replace Type Code with Sublasses и Replace Type Code with Strategy. Оператор Switch (Case) Хороший объектный код очень редко использует операторы Switch. Часто вы видите один и тот же Switch в разных местах. Если вам надо добавить еще один выбор, вам придется искать все операторы Switch. В большинстве таких случаев лекарством является полиморфизм. Если Switch переключается по коду типа, используйте Replace Type Code with Sublasses или Replace Type Code with Strategy. Вам может понадобиться Extract Method и Move Method чтобы изолировать Switch и поместить его в нужный класс. Когда вы настроите структуру наследования, используйте Replace Conditional with Polymorphism. Параллельные иерархии наследования Параллельные иерархии - это частный случай хирургии дробовиком. Каждый раз, когда вы добавляете потомок класса, вы вынуждены добавлять потомок другому классу. Сначала сделайте так, что экземпляры одной иерархии ссылались на соответсвующие экземпляры другой. Потом используйте Move Method и Move Field и вторая иерархия исчезнет понемногу. Ленивый класс Каждый созданный класс стоит вам денег - на его понимание и содержание. Класс, который не делает достаточно, чтобы окупить себя, должен быть уничтожен. Часто это класс, который раньше окупался, но был урезан при рефакторинге. Если он является потомком другого класса, используйте Collapse Hierarchy. Почти бесполезные классы должны подвергнуться Inline Class. Спекулятивное обобщение Это случай когда кто-то говорит: " О, смотрите, нам когда-нибудь понадобится такая-то возможность" и поэтому хочет вставить всякие хуки и специальные случаи чтобы работать с вещами, которые не нужны. Результат получается сложнее в использовании и сопровождении. Если у вас есть абстрактные классы, которые ничего не делают, используйте Collapse Hierarchy. Ненужная делегация может быть удалена с помощью Inline Class. Методы с неиспользуемыми параметрами должны быть подвергнуты Remove Parameter. Временное поле Иногда вы встречаете код, в котором переменные экземпляра используются только в определенных случаях. Это очень затрудняет понимание. Используйте Extract Class, чтобы сделать дом для бедных сироток. Поместите туда весь код, относящийся к этим полям. Также вы можете избавиться от условного кода с помощью Introduce Null Object, для создания альтернативного объекта на случай, когда эти поля не имеют смысла. Цепочка сообщений Если вы видите код, когда клиент просит объект у другого объекта, затем у этого объекта следующий объект и т.п. Это может быть длинная строка getThis методов или последовательность временных переменных. В любом случае, при подобных вызовах, мы явно предполагаем знание о структуре объектов в цепочке. Любое изменение во взаимосвязях повлечет изменение этого кода. Здесь надо использовать Hide Delegate. Посмотрите, зачем используется результат вызова. Используйте Extract Method и затем Move Method, чтобы продвинуть его дальше по цепочке. Некоторые выступают против любой цепочки методов. Мы выступаем за умеренность. Посредник Одно из главных свойств объектов - инкапсуляция. Вы спрашиваете директора свободен ли он для встречи. Он делегирует сообщение своему ежедневнику и отвечает. Вам не надо знать, использует ли он ежедневник, электронную штуковину или секретаря. Однако, это может зайти слишком далеко. Вы смотрите на интерфейс класса и видите, что половина его методов просто делегируют вызовы другим классам. Время использовать Remove Middle Man и напрямую говорить с объектами, которые знают что происходит. Если только некоторые методы делегируют, то напустите на них Inline Method. Если кроме делегации добавляется поведение, используйте Replace Delegation with Inheritance. Неоправданная близость Иногда классы становятся слишком близки и проводят слишком много времени с приватными частями друг друга. Используйте Move Method и Move Field для разделения частей и уменьшения близости. Посмотрите, нельзя ли организовать Change Bidirectional Association to Unidirectional. Если у классов действительно есть общий интерес, используйте Extract Class, чтобы положить общие части в одно место. Наследование часто ведет к неоправданной близости. Потомки всегда знают о предках больше, чем хотелось бы предкам. Используйте Replace Inheritance with Delegation, когда пора покидать дом. Неполный библиотечный класс Зачастую библиотечный класс не совсем нас устраивает, но мы не можем применить что-то типа Move Method к нему. Если вам надо добавить пару методов, используйте Introduce Foreign Method. Если добавлять надо много, вам понадобится Introduce Local Extension. Класс для данных Бывают классы, которые содержат только поля и методы для доступа к ним. Это просто тупые контейнеры для данных и скорее всего, другие классы слишком детально ими манипулируют. Во-первых, примените Encapsulate Field и Encapsulate Collection, пока никто не видел. Посмотрите, где данные класса используются. Попробуйте применить Move Method, чтобы перенести этот код в сам класс данных. Классы для данных как дети. Они нужны на начальных этапах. Но чтобы вести себя как взрослый объект, они должны брать на себя ответственность. Отвергнутое наследство Подклассы наследуют методы и данные от их предков. Но иногда они не пользуются тем, что им дают. Традиционный ответ - иерархия плохая. Вам нужно создать новый порожденный класс и применить Push Down Method и Push Down Field. Но по нашему саркастическому использованию слова традиционный, вы догадались, что мы не будем это всегда советовать. Мы используем наследование для повторного использования. Оно сопровождается плохим запахом, но обычно он не очень силен. Если отвергнутое наследство представляет собой проблему, то воспользуйтесь традиционным советом. Комментарии Удивительно, как часто смотришь на хорошо комментированный код и видишь, что комментарии написаны потому, что код плохой. Комментарии не причина, а индикатор плохого кода. При хорошей организации кода комментарии, зачастую, излишни. ПРИМЕРЫ ШАБЛОНОВ РЕФАКТОРИНГА Сделайте метод закрытым.
Рефакторинг программного кода
Цель работы: научиться выполнять реорганизацию программного кода на основании шаблонов рефакторинга.
Ход выполнения работы
Требования к содержанию работы
Теоретические сведения
Популярное:
|
Последнее изменение этой страницы: 2016-05-03; Просмотров: 1294; Нарушение авторского права страницы
