Структурный рефакторинг

ПО без изменения внешнего поведения кода.
Хорошо сочетается с быстрой разработкой.

Он может проводиться в любом месте итерации, но наиболее эффективно выпол­нять его либо в конце текущей итерации, либо в начале следующей.

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

Текущая итерация

Следующая итерация

анализ

проекти-рование

кодиро-вание

рефакто-ринг

рефакто-ринг

анализ

проекти-рование

кодиро-вание

свойств кода:
дублированный код — одни и те же части кода

в нескольких местах;
длинная подпрограмма-метод — метод, который делает слишком много;
большой класс — класс, который делает слишком много и/или имеет слишком много элементов данных;
длинный список параметров — слишком большое количество данных передается в качестве параметров;
расширяющееся изменение — когда класс должен быть изменен в результате больше чем одного вида изменения;
эффект дробовика — когда одно изменение воздействует на несколько классов;
излишняя зависимость — метод, который обращается ко многим другим объектам с помощью сообщений get (получить), чтобы получить данные для собственных вычислений;
группы данных — данные, которые обычно используются вместе во многих местах и которые следует преобразовать в объект.

впечатляющим результатам. К сожалению, можно также и ухудшить код.
CASE-средства

могут существенно помочь в реализации рефакторинга. Многие инструментальные средства содержат каталоги поддерживаемых рефакторингов.
Фаулер перечисля­ет более шестидесяти методов рефакторинга. Рассмотрим только три из них:
Класс извлечения (Extract Class);
Метод подключения (Subsume Method);
Интерфейс извлечения (Extract Interface).

Методы рефакторинга — основные принци­пы и лучшая практика изменения кода с целью улучшения его понятности, удобства сопровождения и масштабируемости.

Мартин Фаулер
(Martin Fowler )

Класс извлечения и Интерфейс извлече­ния.
Рефакторинг Класс извлечения: «Создайте новый класс

и переместите соответствующие поля и методы из старого класса в но­вый». Нужно извлечь непротиворечивые и объединенные части функци-ональных возможностей в отдельный класс и установить связь ассоциации от старого класса к новому.

Из класса CActioner выделены методы извлечения исходящих сообще-ний (класс CMsgSeeker) и посыл­ки сообщений (CMsgSender).
Связи поддерживаются двумя мето-дами: getMsgSeeker() и GetMsgSender(). Первый получает объ­ект CMsgSeeker, второй – CMsgSender.
setEmployee() используется, чтобы устано­вить ассоциацию от CMsgSeeker к EEmployee. setEmployee() получает объект EEmployee от метода login().

его функциональных возможностей в другой существующий ме­тод.
Метод подключения устраняет метод

retrieveMessage() включением его возможностей в метод retrieveMessages().

самое подмножество интерфейса класса или два класса содержат общую часть

своих интерфейсов». Метод используется, чтобы «выделить под­множество в интерфейс».

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

Два новых класса уровня используют один и тот же метод display(), чтобы показать строку на эк­ране. Будет лучше, если ме­тод display() будет извлечен в интерфейс, реализован в PMenu и исполь­зован при необходимости новыми классами.

в рефакторинге кода.
Паттерны представлены следующими группами:
Коллекция идентичности объектов (Identity Map);
Преобразователь

данных (Data Mapper);
Загрузка по требованию (Lazy Load);
Единица работы (Unit of Work).

Мартин Фаулер называет их паттернами структуры промыш­ленного приложения. Они являются целью тех аспектов системы, которые де­лают ее промышленным приложением в противоположность маломасштаб­ным настольным приложениям. Они имеют дело с такими проблемами, как связь с БД, кэши сохраняемых объектов, расположенные в памяти, управле­ние транзакциями и параллелизмом, представление Web-технологий, работа с распределенными объектами и т. д.

Книга Фаулера перечисляет и документирует более пятидесяти структурных пат­тернов.

заданные (explicit) и общие (generic) коллекции.
К объектам в явно

заданной коллекции идентичности объектов можно иметь доступ (get), их можно зарегистрировать (put) и снять с них регистрацию (remove) с использовани­ем различных методов для каждого класса кэшированных объектов. Напри­мер, для получения доступа к объекту: getEEmployee (new Integer(empOID));
Для объектов в общей коллекции каждая из этих операций выполняются единствен­ным методом для всех классов. Напри­мер: get ("EEmployee", new Integer(OID)).
Фаулер различает одну коллекцию на класс и одну коллекцию на сеанс.
Одна коллекция на сеанс требует глобальных уникальных иденти­фикаторов объектов. Одна коллекция на класс может использовать идентификаторы объектов, уникальные в пределах класса.
В обоих случаях для коллекций идентичности обновляемых объектов должна быть обеспечена защита в виде транзакций и они должны быть помечены как измененные, когда объекты идентичности выходят из синхронизации с соответствующими записями БД.

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

private Map OIDToObj; //OID -> Obj
22: private Map

msgPKToOID; //msgPK -> OID
23:
24: public EIdentityMap() {
25: OIDToObj = new HashMap();
28: msgPKToOID = new HashMap();
29: }
30:
31: /** Получить хранимого делового партнера */
32: public IAContact findContact(int contactOID) {
33: return (IAContact) OIDToObj.get(new Integer(contactOID));
34: }
35: /** Разместить делового партнера с заданным OID */
36: public void registerContact(IEObjectlD oidObject) {
37: OIDToObj.put(new Integer(oidObject.getOID()), oidObject);
41: }
42: /** Снять регистрацию с зарегистрированного делового партнера */
43: public void unregisterContact(IEObjectlD oidContact) {
44: OIDToObj.remove(new Integer (oidContact.getOID()));
46: }
113:}

EIdentityMap — явно заданная коллекция идентичности объектов - она имеет отдельные методы для каждого класса пакета entity. Класс пред­ставляет стратегию одной коллекции на сеанс — он использует глобальные уникальные идентификаторы ОID.

(Mappers), который перемещает данные между объектами и БД, когда они

хранятся независимо друг от друга, и непосредственно сам преобразователь».

Рефакторинг класс извлечения позволяет извлечь обязанности Преобразователя дан-ных из класса MBroker в класс MDataMapper.
MDataMapper отде-ляет пакет entity от пакета foundation .

БД, MDataMapper превращает их в объекты пакета entity. Затем новые

объекты регистрируются в EIdentityMap.
Это — операция загрузки. Процесс загрузки также называется материализацией

объектов в БД. Процесс выгрузки также известен как пассивация или

де­материализация.

Выгрузка требуется, когда объект изменен, удален или создан новый .

чтобы размещать и удалять строки данных у всех объектов па­кета

entity, известных в приложении (EEmployee, EContact и EOutMessage).
MModerator служит Фасадом для пакета mediator. MDataMapper обеспечивает ассо­циации к EIdentityMap, с одной стороны, и к FReader и FWriter, с другой стороны.

итерации могут требовать альтернативных решений, основанных на различных паттернах рефакторинга:
Несколько

Преобразователей данных, возможно, по одному на каждый класс пакета entity.
Использование метаданных и Java-отображения, чтобы динамически формировать в приложении Преобразователи данных по мере необходимости.
Загрузка по требованию, который размещает только данные, необходимые в настоящее время приложению, и, если возможно, создает пустые объекты для данных, не извлеченных из БД, но которые связаны с уже извлеченными данными.

запросами клиента, направленные на различные объекты пакета entity. В случае

большого числа классов пакета entity, Преобразователь данных может стать слишком разрастись.
Альтернативное решение - один Преобразователь данных на каждый класс.
Три преобразователя реализуют, каждый уникальным способом, интерфейс IMDataMapper. MModerator обеспечивает ассоциацию «один ко мно­гим» к объектам IMDataMapper.

объектно-реляционное преобразование, основанное на метаданных.
Хранить метаданные можно:
непосредственно в исходном коде

приложения (в пакете mediator);
во внешнем файле, предпочтительно в XML-файле (приложение читает файл во время инициализации и создает соответствующие преобразования в структуре программы);
в БД (одни и те же метаданные используются несколькими приложениями).

Стратегии включения информации размещения в выполняемом коде:
формирователь кода, который читает инфор-мацию метаданных и формирует классы, до компиляции программы;
рефлексивная программа, которая позволяет настраивать приложение к любой новой информации метаданных во время выполнения.

загрузка (Identity load) — извлечение конкретных объектов, имеющих заданную величину

OID или первичного ключа.
Загрузка на основе логического условия (Predicate load) — извлечение нескольких объектов, выполняя поиск по запросу на основе логических условий.

Основные стратегии загрузки:
Замкнутая загрузка (Closure load) — загружаются все объекты, доступные из указанного объекта.
Простая загрузка (Flat load) — загружаются только указанные объекты без объектов компонентов.
n-уровневая загрузка (n-levels load) — загружаются объекты, достижимые из указан­ного объекта в пределах данного числа уровней.
Замкнутая (активная) загрузка обычно неприемлема. Остальные стратегии - варианты загрузки по требованию.

Подходы, реализующие Загрузку по требованию:
Инициализация по требованию (Lazy Initialization);
Виртуальный заместитель (Virtual Proxy);
Заместитель идентификатора объекта (OID Proxy).

Паттерн Загрузка по требованию определяется как «объект, который не содержит все данные, в которых вы нуждаетесь, но знает, как по­лучить их».

может ис­пользоваться в EOutMessage, если приложение содержит преобразователи дан­ных, в

которых имеется contactOID к загруженно­му объекту EContact, и элемент данных, содержащий contactID, кото­рый соответствует внешнему ключу в БД. Когда запрашивается getContact(), тот проверяет, является ли contactOID пустым. Если да, то посылается сообщение retrieveContact() объекту MDataMapper, чтобы за­грузить его.

По запросу от объекта-клиента Преобразователь данных ищет кэш данных и, если данных там нет, загружает их из БД.

Попытка Преобразователя данных получить данные из кэша может быть выполнена по значению элемента данных в объекте. Если значение null, то Преобразователь данных должен инициализировать эле­мент данных, обращаясь к БД.

Метод getContact() в EOutMessage
public IAContact getContact()
{ if (contactOID == null)
contact = MDataMapper.retrieveContact(contactID);
return contact;
}

в роли реального объекта. Он получает сообщения, предназначенные для ре­ального

объекта (который называется реальным субъектом в Виртуальном заместителе) и создает реальный объект, если он еще не существует.

В Заг­рузке по требованию заместитель обозначает объект, который может потре­боваться загрузить при попытке обратиться к нему.

быть загружен и что EContactProxy (класс «за-меститель делового парт-нера») знает

РК своего реального субъекта. Когда MDataMapper соз-дает EContactProxy, он инициализирует его поле contactID соответствую-щим значением FK в EOutMessage.
Когда MDataMapper запрашивает делово­го партнера (getContact()), EOutMessage возвращает EContactProxy.

Предположим, что объек­ты пакета entity идентифицированы своими первичными ключами (РК).

что-бы инициализиро-вать его. Затем EContactProxy может возвратить firstName.
Следующий запрос относитель-но

familyName, выполняется подоб-ным же образом за исключением того, что EContact уже загружен.

Когда на следующем шаге MDataMapper запрашивает, например, firstName делового партнера, EContactProxy проверяет, существует ли реальный субъект (EContact).

кото­рый обеспечивает задание OID объектам выполняет функции замещающих классов. Такой

подход мо­жет быть зарегистрирован в паттерне — паттерне Заместитель идентифика­тора объекта.
EIdentityMap знает, загружен ли объект пакета entity. После загруз­ки объекту задается OID, и все его элементы данных инициализируются. Инициализация включает значения внешних ключей (FK), полученные из БД. Основанные на OID связи ассоциации, соответствующие внешним ключам, инициализируются значением null, если связанный объект не был еще за­гружен.

Имеются две разновидности Заместителя идентификатора объекта:
навигация по коллекции идентичности объектов;
навигация по классам пакета entity.

Дополнительное преимущество Заместителя идентификатора объекта над Виртуальным заместителем — легкость, с которой может быть опреде­лено измененное/не измененное состояние объекта пакета entity. Для объ­екта пакета entity, загруженного первым, устанавливается флаг неизменен­ного объекта. Если содержание данных объекта выходит из синхронизма со своим соответствующим содержанием в БД, flag (флаг) устанавливается в состояние «измененный». Объект пакета entity всегда знает свое состояние и может вызывать перезагрузку из БД, чтобы обновить содержание.

contactOID класса EOutMessage служит за­местителем объекта Econtact. MDataMapper содержит список

OID всех объектов, загруженных в памя­ть. По значению РК объекта (например, outmsgID), может быть запрошен EIdentityMap о соответствующем OID.

изменен он или нет. Это проверяется методом isDirty(). EIdentityMap запрашивает

getContact() у EOutMessage. EOutMessage проверяет, является ли значение внешнего ключа к EContact пустым и равен ли contactOID null. Если да, то EContact не был загружен. EIdentityMap запрашивает MDataMapper, извлечь EContact по значению FK. Econtact загружается. MDataMapper корректирует свой список OID. EIdentityMap корректирует свои коллекции, a в EOutMessage устанавлива-ется contactOID. EContact возвращается к client object, который может теперь непосредственно запросить его данные (getFirstName(), getFamilyName() и т.д.)

Объекты пакета entity содержатся в коллекциях EIdentityMap. Они имеют только OID к другим объектам.

пакета entity не содержал лишь OID к другому объ­екту, а

содержал сам этот объект.

После определения, что EOutMessage не изменен, MDataMapper сооб­щает это методу getContact(). Если EContact не загружен, EOutMessage инициирует загрузку. Он передает свой outmsgOID объекту MDataMapper, чтобы новый EContact мог быть связан с ним, когда будет зарегистрирован в EIdentityMap.
Логика по загрузке EContact заметно переме-стилась к EOutMessage.

загружаются если они: 1) не были загружены, 2) стали измененными.

Для упрощения итерация 1 объявляет весь кэш измененным, как только будет передано по электронной по­чте любое EOutMessage. Флаг измененного состояния находится в классе MBrоkеr.

Метод updateMessage() в MModerator
87: public boolean updateMessage(IAOutMessage msg) {
91: msg.setSentDate(new Java.sql.Date(System.currentTimeMillis()));
92:
93: boolean b = mapper.storeMessage(msg);
94: if (b) {
96: msg.setContact (null);
97: msg.setCreatorEmployee(null);
98: msg.setSenderEmployee(null);
99: msg.setDirty(true);
100: }

После того как сообщение EOutMessage будет передано по электронной почте, MModerator посылает сообщение setDirty() измененному объекту EOutMessage (стр.99).

После рефакторинга флаг изменен­ного состояния появляется в каждом объекте.
При загрузке флаг объекта очищается. Флаг устанавливается измененным, когда объект изменится.

объект пакета entity знает, является ли он изменен­ным или нет,

позволяет осуществить индивидуальную загрузку и выгрузку объектов. Однако многие бизнес-транзакции, управляемые приложением, де­лают многочисленные изменения у разнообразных объектов в кэше перед по­пыткой записать эти изменения в БД. Измененные объекты должны быть со­ответственно помечены как измененные, когда БД подтверждает, что тран­закция успешно завершена. Эти проблемы быстро становятся очень сложными.

Паттерн Единица работы требует создания нового класса в пакете mediator. Класс можно назвать MWorkUnit.

Паттерн Единица работы «обслуживает список объектов, на которые воздействует бизнес-транзакция, и координирует перезапись изменений и решение проблем параллелизма». Изменения могут быть следствием трех операций модификации: размещения нового объекта в БД, удаления объекта из БД или обновления элементов данных объекта.

структуры кода без изменения его внешнего поведения.
Методы рефакторинга — основные

принципы и лучшая практика изменения кода для улучшения возможности его сопровождения (понятности, удобства сопровождения и масштабируемости).
Рефакторинг Класс извлечения расщепляет большой класс на ряд меньших классов.
Рефакторинг Метод извлечения преобразует дублированный код в отдельный метод.
Рефакторинг Метод подключения устраняет метод включением его функциональных возможностей в другой существующий метод.
Рефакторинг Интерфейс извлечения выделяет множество сигнатур методов, дублированных в нескольких классах или используемых несколькими клиентами, в интерфейс.
Паттерны рефакторинга — структурные паттерны, используемые в рефакторинге кода.
Паттерн Коллекция идентичности объектов назначает идентификаторы объектам и поддерживает коллекции, чтобы найти объекты, находящиеся в памяти, на основе их идентификаторов.
Паттерн Преобразователь данных отделяет объекты, находящиеся в памяти, от их представления в БД и отвечает за поддержание кэшей памяти объектов.

из БД и преобразования их в объекты памяти. Противоположная операция

называется выгрузкой (экспортом, пассивацией, дематериализацией).
Паттерн Загрузка по требованию загружает только отобранные объекты из БД в память, но он может загружать оставшиеся и связанные объекты, когда это необходимо. Подходами к Загрузке по требованию являются Инициализация по требованию, Виртуальный заместитель и Заместитель идентификатора объекта.
Паттерн Инициализация по требованию загружает объекты по определенному запросу от объекта-клиента, ответственного за поддержание кэша пакета entity. Загрузка для клиентов не прозрачна.
Паттерн Виртуальный заместитель использует объект-заместитель, который является заменой реального объекта и может загрузить реальный объект способом, прозрачным для клиента.
Паттерн Заместитель идентификатора объекта — удобная замена паттерна Виртуальный заместитель в приложениях, которые поддерживают коллекции ОID объектов. Коллекции могут использоваться вместо классов-заместителей. Имеются две разновидности Заместителя идентификатора объекта, которые отличаются тем, как программа реализует навигацию между связанными объектами: Навигация по коллекции идентичности объектов и Навигация по классам пакета entity.

Коллекция идентичности объектов каждый раз, когда приложение должно осуществить навигацию

к связанному объекту пакета entity (то есть связанному ссылочной целостностью). Если объект X связан с объектом Y, Коллекция идентичности объектов должна запросить X, чтобы получить связь с Y, и затем осуществляет доступ к Y.
Навигация по классам пакета entity использует классы пакета entity, чтобы осуществить навигацию по связанным классам. Если объект X связан с объектом Y, Коллекция идентичности объектов позволила бы клиенту осуществить доступ к X, но затем передает управление к X, чтобы продолжить навигацию к Y.
Паттерн Единица работы обеспечивает приложение знанием проблем о бизнес-транзакциях и параллелизме. Он хранит последовательность изменений объектов пакета entity и то, действительно ли изменения были переданы в БД.

примера / Л.А. Мацяшек, Б.Л. Лионг. – М.: БИНОМ. Лаборатория

знаний, 2009. – 956 с.
2. Фаулер М. Рефакторинг: улучшение существующего кода. – СПб.: Символ-Плюс, 2002.
3. Фаулер М. Архитектура корпоративных программных приложений. – М.: Издат. дом «Вильямс», 2006. – 544 с.
4. Ларман К. Применение UML и шаблонов проектирования. 2-е издание. – М.: Издат. дом «Вильямс», 2002. – 624 с.
5. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приёмы объектно-ориентированного программирования. Паттерны проектирования.- СПб.: Питер, 2006
6. Шаблоны проектирования. – url: http://ooad.asf.ru/Patterns.aspx