DarkGoodWIN - Рефакторинг. Зачем?

3. Математические выражения также редко удаётся разбить на составляющие. Например, если вы что–то считаете по формуле — вам будет крайне сложно придумать адекватное название для расчёта части этой формулы.

4. Когда функция вам не мешает. То есть не следует проводить рефакторинг ради рефакторинга, маниакально выискивая «плохие» места в коде. Куда разумнее улучшать код только после того, как наткнулся на него в рамках какой–то задачи или более крупного рефакторинга.

Причин так говорить у меня сразу несколько. Во–первых, если вы раньше не натыкались на фрагмент кода, то может и в будущем никогда не наткнётесь, зачем же тратить на него время, если он нормально работает и пока никому не мешает? Во–вторых — не стоит забывать, что любой рефакторинг, как бы аккуратно он не проводился — это риск что–то испортить. Опять же, зачем рисковать просто так? Ну и наконец, всегда есть вероятность, что после рефакторинга вы через какое–то время поймёте, что логику надо поменять, а может и вовсе помножить на ноль эту ветку кода и что получится? Вы потратили время на улучшение уже устаревшего кода, то есть впустую, а могли, например, лишний раз протестировать функциональность или написать пару тестов.

Удобно когда всё в одном файле и ничего искать не нужно? С одной стороны, конечно, да. Но это справедливо только для весьма небольших проектов.

Возможно повторюсь, но система каталогов — это по сей день самая удобная и понятная с система организации данных. Как я уже говорил — самое простое — организация данных по алфавиту. Нам это мало подойдёт. Не слишком удобно в случае программирования. Куда интереснее — тематический каталог.

Классические примеры — разнесение функций для работы с графикой (интерфейсом) и непосредственно логики программы. Часто выносят в отдельные модули функции для работы со строками, модули, отвечающие за сериализацию.

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

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

В программировании есть понятие — простые типы данных. Традиционно к ним относятся целые числа, числа с плавающей точкой, булевы (логические) типы данных, а также строки.

Множество переменных простых типов могут объединяться в массивы, но это ещё не всё. По–настоящему гибким программирование стало с появлением классов.

Это понятие, на мой взгляд, одно из самых трудных для понимания начинающих программистов, поэтому, я планирую уделить ему достаточно много времени, прежде чем перейти непосредственно к рефакторингу. Если вы знакомы с классами — вам может стать скучно, в таком случае — можете пропустить эту главу.

Я уже писал, что название переменной должно отражать её содержимое. То есть переменная с названием Line — должна каким–то образом описывать отрезок или прямую. Чаще всего данную сущность описывают двумя точками. Если пользоваться только простыми типами — нам придётся завести 4 переменные, например, X1, Y1, X2, Y2. А в случае, если у нас несколько линий, для того, чтобы отличать одну от другой — нам придётся переназвать переменные, например: Line1X1, Line1Y1, Line1X2, Line1Y2. Не очень удобно, правда?

Для решения подобных задач, уже давно, был придуман новый тип данных — record или struct, в зависимости от языка. Сейчас этот тип практически полностью вытеснен классами и его использование для большинства задач считается плохим тоном. Поэтому не буду останавливаться на этом, тем более, что рефакторинг к рекордам практически не применим.

И так, мы решили создать класс для нашей линии. Вот так видит декларация (описание) класса:

type

TLine = class(TObject)

public

X1: Integer;

Y1: Integer;

X2: Integer;

Y2: Integer;

end;

В данном случае — ключевое слово type — определяет начало блока объявлений новых типов данных. Стандартная конструкция языка Pascal. Для других языков синтаксис будет отличаться. TLine — н азвание нашего класса. “= class(TObject)» — означает, что мы определяем класс, наследованный от класса TObject . Это базовый класс в Object Pascal. Все классы так или иначе наследованы от него. Подробнее на эту тему поговорим, когда будем обсуждать наследование.

Ключевое слово public определяет область видимости переменных и функций, объявленных в текущем блоке. Подробнее об этом также поговорим после. Ключевое слово end завершает определение класса.

Мы создали новый класс, но как им пользоваться? Для этого надо создать экземпляр класса:

var

Line: TLine;

begin

Line:= TLine. Create;

end;

В данном фрагменте кода мы объявляем переменную Line типа TLine , после чего, создаём новый экземпляр класса TLine и присваиваем его переменной Line .

Часто путают понятия класс и объект, так вот, в нашем случае объект — это Line , а класс — TLine .

В прошлой главе мы создали новый класс, научились создавать экземпляры классов и на этом закончили. Давайте эту главу начнём с примера использования данной конструкции:

function CalculateLineLength(Line: TLine): Double;

begin

Result:= Sqrt(Sqr(Line. X2 — Line. X1) + Sqr(Line. Y2 — Line. Y1));

end;

var

Line: TLine;

LineLenght: Double;

begin

Line:= TLine. Create;

Line. X1:= 10;

Line. Y1:= 10;

Line. X2:= 20;

Line. Y2:= 20;

LineLenght:= CalculateLineLength(Line);

end;

Тут мы создаём новую линию и рассчитываем её длину. Для этого мы завели вспомогательную функцию CalculateLineLength .

Если приглядется, то в нашей новой функции слишком часто упоминается название переменной Line . Возможно есть способ сделать код несколько проще и наглядней? К счастью да. Дело в том, что функцию можно перенести непосредственно в класс:

type

TLine = class(TObject)

public

X1: Integer;

Y1: Integer;

X2: Integer;

Y2: Integer;

function CalculateLineLength: Double;

end;

function TLine. CalculateLineLength: Double;

begin

Result:= Sqrt(Sqr(X2 — X1) + Sqr(Y2 — Y1));

end;

В месте использования код также становтся наглядней. Строка LineLenght:= CalculateLineLength(Line); заменится на строку: LineLenght:= Line. CalculateLineLength; , что несколько короче и куда лучше подчёркивает тот факт, что функция относится именно к линии, а не к чему–то ещё.

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