Комментарии к исходной программе

Каково ваше впечатление о дизайне этой программы? Я бы сказал, что она не очень хорошо спроектирована и, несомненно, не является объектно-ориентрированной. Для такой простой программы это не так уж и важно. То есть для простой "quick and dirty" программы это нормально. Но если это важный фрагмент более сложной системы, то возникают реальные проблемы. Длинный метод в классе Customer берёт на себя слишком много. Многие вещи из него на самом деле должны делаться другими классами.

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

В нашем случае пользователи хотели бы видеть следующие изменения. Во-первых, им нужны отчеты в виде HTML, готовые для публикации на WWW и должным образом разукрашенные. Каковы же могут быть последствия этих изменений? Взглянув на исходный код, вы уже могли видеть, что части существующего метода statement не получится повторно использовать для печати отчета в HTML. Можно видеть, что придётся написать полностью новый метод, дублирующий большую часть метода statement. Разумеется, в данном случае это не очень обременительно. Можно просто скопировать метод statement и поменять всё, что требуется. Но что, если после этого изменятся правила расчёта задолженности? Вам потребуется вносить изменения в оба метода, statement и htmlStatement, а после этого убедиться, что изменения соответствуют друг другу. Проблема с копированием и вставкой кода возникает тогда, когда вам приходится менять его позже. Конечно, если вы пишете программу, котрую не планируете менять в дальнейшем, то копирование и вставка подходят замечательно. Но если программа будет жить долго и, вероятно, будет изменяться, то копирование и вставка опасны.

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

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

Возможно, вы соблазнитесь внести несколько изменений в программу; после этого она даже будет работать. Помните старую поговорку: "если не сломано, то не стоит чинить". Программа может быть исправной, но причинять неприятности. Она сделает вашу жизнь более трудной, потому что вам будет тяжело вносить изменения, нужные пользователям. Вот тут и приходит время для рефакторинга.

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

В начало | предыдущая | следующая