Инженерные практики Agile (comp.soft.prog.agile) : Рассылка : Subscribe.Ru

← Март 2008 →
	1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

← Март 2008 →

Рефакторинг enum

[Flags]
public enum FormButtonType
{
OK,
Cancel,
Print,
}

class...
private void SetupFooterButtons()
{
...

FormButtonsAttribute buttonsAttribute = DomainObjectHelper.GetDefinedAttribute<FormButtonsAttribute>(GetType());
foreach (FormButtonType button in formButtons.Keys)
{
bool buttonDefinedOnForm = ((buttonsAttribute.Buttons & button)
== button);
formButtons[button].Visible = buttonDefinedOnForm;
}
...
}

Попробуйте подумать, как рефакторинг посмотрит на этот код :)

denis miller

ответов: 0 2008-03-03 17:12:03 (#729302)

Я выхожу в подкаст

Сегодня необычная рассылка.

Буквально совсем вчера :) в сети появлся подкаст! Куда я вас и приглашаю - http://agile.rpod.ru
На моём подкасте вы сможете прослушать мои последние мысли. Делается это просто.
Слева у каждого выпуска есть мини-плеер. Надели наушники, нажали проигрывать
и пытаетесь понять о чем речь. Потом нажимаете комментировать и мы начинаем обсуждать
:)

Цель подкаста - самовыражение. Суть подкаста - публикация того, что я могу делать,
что мне нравиться. Список тем: agile, scrum, extreme programming, design patterns,
architecture patterns, agile modeling, test-driven development, refactoring,
smells и все другие буз-ворды! Подцель - возбуждение интереса и дискуссий!

Вперёд товарищи! На баррикады!

denis miller

ответов: 0 2008-02-23 02:48:43 (#727109)

Задача. constPresentation

Предлагаю обсудить следующее решение, и найти лучший вариант:

public class constPresentation {

public static final String ITEM_CAPTION1 = ...;
public static final String ITEM_CAPTION2 = ...;
....

}

Потом оказалось, что надо поддерживать несколько интерфейсов.
Тогда я это реализовала след. образом:

У меня появился абстрактный класс:

public abstract class base {
protected String String ITEM_CAPTION1;
protected String String ITEM_CAPTION2;
...

public String getITEM_CAPTION1() {return ITEM_CAPTION1;}
public String getITEM_CAPTION2() {return ITEM_CAPTION2;}
...
}

И классы с конкретными значениями. Эти классы являются наследниками класса base:

public class constRu extends base {
public constRu(){

ITEM_CAPTION1 = "...";
ITEM_CAPTION2 = "...";
....
}
}

public class constEn extends base {
public constEn

ITEM_CAPTION1 = "...";
ITEM_CAPTION2 = "...";
....
}
}

А исходный класс constPresentation преобразовался след. образом:

public class constPresentation {

private static base b = getConstants();

public static final String ITEM_CAPTION1 = b.getITEM_CAPTION1();
public static final String ITEM_CAPTION2 = b.getITEM_CAPTION2();
....

private constPresentation(){}

...

private static baseConstants getConstants(){

if (isRuInterface()){
return new constRu();
}
if (isEnInterface()){
return new constEn();
}
return new constNull();
}

}

Ответы присылайте на адрес: comp.soft.prog.agile-list@subscribe.ru (или просто
нажмать "ответить")

denis miller

ответов: 0 2008-02-07 14:33:11 (#723410)

Продолжаем бороться с переменными

Добрый день,

Сегодня заметки будут о временных переменных внутри функции.

Временные переменные плохи тем, что они временны и локальны. Временные переменные
локализуются в функциях. Поэтому мы знаем, где их искать.
Если мы использовали TDD, то все функции масенькие, изолированные и простые.
Там негде образовываться временным переменным. Поэтому этим переменным свойственно
появляться в длинных, длиннющих и огромных функциях. Знакома ситуация?

double total = order.Discount(); (1)
или
double total = quantity * cost; (2)

Решение здесь простое. Если они локальны, один раз инициируются и мешают нам
упрощать код функции, то каждая переменная превращается в функцию (2) или подставляется
собственно простое выражение (1). То есть удаляем переменную total, а заводим
функцию totaol(). И везде производим замену.

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

С Уважением,
Денис Миллер

denis miller

ответов: 0 2008-02-02 02:12:54 (#722274)

Ох уж эти переменные

Добрый день,

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

Да конечно, в каждом проекте главный разработчик изобретает свою конвенцию, и
насилу заставляет работать остальных. Странно? Ведь главный на то и главный,
чтобы делать так, чтобы его решения удовлетворяли максимальное количество людей.

И основной религизной темой является использование типа в наименовании. Закалённые
в боях разрботчики конечно же воспримут духом при упоминании бузворда <<Венгерская
нотация>>. Но всё таки на дворе XXI век и стоит посмотреть какой ветер дует.

Итак. Тип в наименовании - это:
* iCounter,
* strName,
* Collection.AddCourse(Course a)
* _field
* ITS_CONSTANT

Это пережитки прошлого, когда код печатался на бумаге, когда редакторы были текстовые,
когда не было всплавающего разнообразия, когда... когда... и к тому же нас учили
так в институте :)

Мы живём в мире ООП, TDD и рефакторинга (!). А эти вещи говорят
1. Переменная должна отражать НАМЕРЕНИЕ
2. Переменная должна показывать РОЛЬ, а не тип
3. Если вам трудно понять что есть что, то приглядитесь а не слишком ли у вас
большой класс, что вы заблудились в трёх соснах
4. Пользуетесь IDE

Ваше мнение?

С Уважением,
Agile-фанатик
denis miller

Литература:
1. Refactoring Workbook By William C. Wake
2. Kent Beck. Implementation Patterns

denis miller

ответов: 0 2008-01-28 23:38:06 (#721246)

Новая рассылка "Инженерные практики Agile"

Добрый день, читатель!

Это первый выпуск рассылки, посвящённый вопросам качественного кода. Рассылка,
думается, будет неким мастер-классом, в которой будут обсуждаться вопросы гибкого
дизайна, вопросы поддержки и развития архитектурных решений, но самое главное
чистоты, простоты и понятности нашего с вами кода.

Причём тут Agile? Agile как подход быстрой разработки программного обеспечения
накладывает серьезные требования к разработчикам (основной производственной силе
проекта). Поэтому основатели Agile ещё задолго до определения манифеста (см.
http://agilemanifesto.org) разработали множество полезных техник, подходов и
практик. А после подписания манифеста эти подходы стали основными инструментами
Agile-команд. Это - рефакторинг, design patterms, implementation patterns, patterns
of enterprise application architecture, test-driven development, agile modeling,
CRC и другие (включая стандартные подходы: UML, Use Cases и т.п.)

Организована рассылка будет просто. Раз в неделю, а может быть чаще я (с учётом
ваших писем) буду выделять одно из решений в области качественного кода. Конечно
же за подсказками обратимся к Макконелу, Фаулеру, Кент Беку и другим авторам.
Но и сами попытаемся разобраться к чему приведёт нас то или иное решение.

Думаю, что для первого сообщения достаточно. В заключение сразу предлагаю перейти
к целям рассылки. Давайте обсудим решение <<Encapsulate Fields>>

Encapsulate Field: There is a public field. Make it private and provide accessors.

Вариант 1.
public String _name

Вариант 2.
private String _name;
public String getName() {return _name;}
public void setName(String arg) {_name = arg;}

Литература: Мартин Фаулер. Рефакторинг.

Я всегда делаю вариант 2. Скрытие данных за вызовом метода позволяет мне более
гибко управлять данными. Так я могу сделать <<отложенное создание>> или вообще
перенести данные в другой класс, например базовый 

Что вы думаете?

С Уважением,
Денис Миллер

denis miller

ответов: 0 2008-01-27 18:08:09 (#720956)