Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Создание сайта и его продвижение" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
| ← Ноябрь 2004 → | ||||||
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|---|---|---|---|---|---|---|
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
|
15
|
16
|
17
|
19
|
20
|
21
|
|
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|
|
29
|
30
|
|||||
Статистика
-4 за неделю
Элементы проектирования в XP и рефакторинг.
| Информационный Канал Subscribe.Ru |
Мир экстремального программирования
Здравствуйте Дорогие Подписчики,
Хочу поблагодарить всех за интерес к моей работе и экстремальному программированию. Сразу похвастаюсь выпуском нового релиза DevPlanner-а. Кому интересно может посмотреть на CNet. Надеюсь, теперь вечера у меня будут немного свободней, что даст возможность уделить время данной рассылке, новым статьям и переводам по XP.
Элементы проектирования в XP и рефакторинг
Ни для кого не секрет, что хороший дизайн - залог успеха любого серьёзного проекта. Правда, почему-то у многих сложилось впечатление о несостоятельности проектирования в экстремальном программировании. Попробую убедить в обратном с помощью рефакторинга.
Рефакторинг - приведение кода и проекта в целом к формализованным паттернам проектирования, для чего, собственно, и служат паттерны рефакторинга. Сразу рассмотрим пример.
Необходимо извлечь название домена из разных типов URL. Обычно это делают так:
string UrlParser::GetDomainName(UrlType urlType, string url)
{
switch(urlType)
{
case HTTP:
{
// Extracts xprogramming.com.ua
// from http://xprogramming.com.ua/index.php
}break;
case EMAIL:
{
// Extracts xprogramming.com.ua
// from mailto:sashaf@xprogramming.com.ua
}break;
}
}
Но объектно-ориентированное программирование рекомендует выделить специфичное для каждого типа поведение в отдельный класс.
Это называется заменой условного оператора полиморфизмом.
Из данного примера можно сделать вывод, что необходимо сразу проектировать ветвистую иерархию классов. Отнюдь, на начальной стадии очень сложно предугадать будет ли этот шаг полезным или наоборот, губительным. Приведу другой пример из личной практики.
Пару лет назад я работал над проектом по отображению структуры кода в виде дерева, своеобразный Class View. Начитавшись умных книг по UML, я набросал вот такую диаграмку:
Я привожу её в упрощённом виде для чистоты примера. Методы GetIcon и GetType возвращали жёстко закодированную константу. Методы GetName всех порождённых классов просто обращались к базовому. Во время рисования диаграммы я предположил, что имя может как-то декорироваться в зависимости от типа элемента. Но такого требования в процессе не возникло и переопределённые методы болтались просто так. Всё бы ничего, но начали появляться всевозможные дополнительные элементы, которые нужно было отображать в Class View. Добавлять новый класс для каждого типа было не совсем удобно. Я стал подумывать о свёртывании иерархии. Действительно, это помогло. Сначала я удалил все переопределения GetName. Так как, GetType и GetIcon возвращали одно и то же значение для конкретного типа, я их совместил в одном GetTypeIcon. Затем я применил замену подкласса полем. Вот что получилось:
Можно долго спорить о необходимости такой иерархии в начале проекта, но как показывает опыт, полезность этого - лишь вопрос везенья или гадания на кофейной гуще. Так XP и говорит: сделайте то, что проще, не пытайтесь предугадать непредсказуемое!
Экстремальное программирование не просит отказаться от проектирования, напротив, проектирование приветствуется, только в разумном количестве и по мере необходимости, пусть даже и в разгаре разработки.
До новых встреч,
Ведущий рассылки, Александр Федоренко.
| http://subscribe.ru/
http://subscribe.ru/feedback/ |
Подписан адрес: Код этой рассылки: comp.soft.prog.xprogramming |
Отписаться |
| В избранное | ||
