Благодаря использованию возможностей языка, нам удалось за основу документа взять стандартный контейнерный класс TSringList. Это самый общий пример эффективного программирования. Тщательно разработанный код для TStringList удалось использовать повторно. Как следствие, отпала необходимость создавать методы для добавления, удаления, доступа к элементу по номеру, хранения строк и связанных с ними объектов. Этот же механизм наследования позволил упростить и собственно нашу часть программирования. Мы разработали лишь основу программы, но можем надеяться, что оставшаяся часть решения задачи существенно упростится. Во–первых определенные выше классы естественны для телеконференций, во–вторых все они производные от (являются разновидностью) документа, и их использование унифицировано: методы имеют одинаковый смысл и имена, а виртуальные методы позволяют не выяснять точный класс каждого объекта.
Что бы кто–либо другой мог воспользоваться нашими трудами, необходимо снабдить разработанные классы описаниями. Их структура оказалась как будто специально приготовлена для этого: необходимо описать лишь интерфейсную (public) часть TDoc, небольшие изменения в TTalk, TFileDoc и TConf, неплохо также привести пример создания, использования и уничтожения объекта каждого класса. Обратите внимание на то, что для пользователя документируется только интерфейсная часть, например, ничего не нужно объяснять о сохранении докладов. Доклад добавляется в конференцию и всё. Остальное будет сделано при сохранении конференции.
Мы скрыли поля данных и отгородили пользователя от неправильного вмешательства в наши объекты. Примером такого вмешательства может служить манипулирование полем FStored. Пользователю наших классов не позволено самостоятельно задавать значение этого поля. Сделав это для конференции, он столкнулся бы с ошибками. Теперь, если в программе обнаружена ошибка, мы отнесем ее в одну из категорий:
1. ошибка не связана с использованием TDoc или его потомков;
2. действия пользователя не соответствуют описанию наших классов;
3. допущена ошибка в описании;
4. ошибка в проектировании или кодировании нашей части программы.
Из–за ясности описаний пункты 2 и 3 проверить достаточно легко. Обсудим последний пункт в нашем списке.
Допустим удалось установить, что TFileDoc загружается правильно, а TConf с ошибкой. В этом случае главное внимание следует уделить методу TConf.LoadBody. Поскольку его тело содержит всего 11 строк, а первая, вторая и одиннадцатая строки правильные, можно рассчитывать, что с оставшимися восьмью мы справимся за разумное время. Если же наоборот, обнаружилось, что ошибка в TFileDoc.LoadBody, то после ее исправления автоматически заработает и TConf.
Таким образом, в результате наследования наши методы выполняют достаточно сложные действия, оставаясь короткими. С другой стороны, исправление ошибок в базовом классе уменьшает количество ошибок и в классах–потомках. Всё это позволяет быстрее получать правильно работающие программы.
Предположим далее, что возникла необходимость изменить содержание заголовка документа. В скольких процедурах нужно будет внести изменения? Скорее всего в двух: TDoc.LoadHdr и TDoc.Store — остальные изменятся автоматически. Эта устойчивость к изменениям — тоже результат проектирования.
Опубликовал Kest
October 12 2011 13:38:48 ·
0 Комментариев ·
6065 Прочтений ·
• Не нашли ответ на свой вопрос? Тогда задайте вопрос в комментариях или на форуме! •
Комментарии
Нет комментариев.
Добавить комментарий
Рейтинги
Рейтинг доступен только для пользователей.
Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.
Нет данных для оценки.
Гость
Вы не зарегистрированны? Нажмите здесь для регистрации.
Главная
Каталог файлов
