Довольно часто клиенты просят меня исправить какие-либо проблемы или добавить некоторую функциональность в существующий код. В большинстве случаев код пишется в течение нескольких лет и никогда не подвергается рефакторингу. Чаще всего это приводит к тому, что такой код тяжело читать, понимать и поддерживать.
1. Введение
В данной серии статей я постараюсь показать, как можно легко улучшить ваш код используя простые ОО-техники и рефакторинг. При написании Delphi-кода я использую определенные правила.
Скорее всего они займут несколько страниц, но вот те, с которых вы можете начать:
- Записывайте, что делает Ваш код
- Подумайте, прежде чем написать первую строчку кода!
- Набросайте небольшую диаграмму/иерархию классов если это необходимо
- Если Вы копируете/вставляете один и тот же код более 2-х раз - пришло время рефакторинга! (тоже правило действует, если Вы просто пишете один и тот же код)
- Классы должны делать то, для чего они предназначены - не больше, не меньше
- Старайтесь мыслить в плоскости объектов и их предназначения, а не процедур и процессов!
Для иллюстрации этих правил я буду использовать маленький кусок кода, который может пригодится практически в любом приложении: сохранение и загрузка настроек. Это довольно простая задача, но в некоторых случаях код, предназначенный для этого ... эээ ... не лучший пример ОО-программирования. Поэтому, давайте посмотрим, чем нам может помочь наш небольшой список правил.
2. Разбор "Правил"
Записывайте, что делает Ваш код
Думаю, что практически каждое приложение хранит какие-либо настройки. В принципе не важно, используете Вы для этого ClientDataSet или INI-файл, текстовый файл или даже реестр Windows. Важно лишь, что приложение может иметь некоторые настройки, пользователь может изменять их, а программе требуется их загружать и сохранять.
Таким образом мы записали, что должен делать наш код. Конечно, в дальнейшем мы можем изменить описание или добавить что-то новое, но уже сейчас у нас есть все, чтобы приступить к написанию кода.
Еще одно преимущество состоит в том, что мы уже написали простейшую документацию к коду! Это действительно неплохо, т.к. если Вам придется документировать код после разработки, есть шанс что этой документации у Вас не будет. Конечно, изменять документацию следует по необходимости, но уже есть с чего начать.
Подумайте, прежде чем написать первую строчку кода!
Во время описания того, что делает Ваш код, подумайте над тем, как он это будет делать, что для этого нужно, ...
Нашему коду потребуются:
- Какие-либо настройки приложения
- Какой-либо способ их загрузки
- Какой-либо способ их сохранения
- Какое-либо место их хранения
- Какой-либо способ их отображения
- Какой-либо способ их редактирования
- Какая-либо форма для их отображения/редактирования
- Какой-либо способ применения настроек
В целях упрощения, предположим, что настройки нашего приложения хранятся в реестре Windows. Мы, конечно, можем сделать механизм сохранения/загрузки универсальным для реестра Windows/INI-файлов и др., но это (пока) для нас не главное.
Что дальше?
Итак, хорошее время, чтобы закончить первую статью. В следующей части мы рассмотрим остальные правила, и посмотрим, как можно улучшить старый код. А пока есть время подумать над тем, что должен делать наш код, и набросать маленькую диаграмму классов...
