Общие руководящие принципы

Теперь, обсудив причины построения собственных компонентов, рассмотрим планирование построения компонентов для некоторого проекта. Как и ранее, предполагается, что это не первое знакомство с темой.

• Компонент должен быть полным. Одиночный метод или функция, реализующие алгоритм, сами по себе не являются компонентами, несмотря на то, что компонент можно построить из функции, выполняющей некоторое важное или сложное действие. Учтите также, что частично реализованный компонент очень сложно использовать: время, сэкономленное на создании компонента, намного меньше будущей экономии времени для завершенного компонента. Сказав это, нужно помнить, что, как и для многих процессов разработки программ, построение компонента часто требует нескольких итераций (или контрольных версий) и включает множество «проб и ошибок».

• Компонент должен быть целенаправленным. Каждый компонент должен иметь единст­венное назначение, а не несколько. Другими словами, избегайте построения компонента типа «швейцарского армейского ножа», позволяющего отобразить графический образ на экране, извлечь данные, проверять вашу электронную почту в сети компании, сохранять данные на сервере InterBase и, возможно, одновременно приготовить чашечку кофе. Вместо этого постройте набор взаимосвязанных компонентов, даже если эти компоненты относятся к одной области. Именно это делают многие продавцы компонент, предоставляя требуемые коллекции компонентов, информированных о данных, компонентов для Internet, информирующих компонентов и т.д.

Примечание

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

• Компонент и его методы, свойства и события должны быть простыми для понимания.

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

• Компонент должен делать нечто новое. Перед созданием компонента проверьте, есть ли уже компонент, выполняющий точно то же самое. В частности выясните, не написал ли Borland такой компонент для Delphi, и не является ли он бесплатным. (Удивительно, сколько компонентов IniFile и Registry делают точно то же, что и собственные классы Delphi TIniFile и TRegistry.) Конечно, если можно улучшить существующий компонент, идите вперед создавайте новый.

• Отладьте ваши компоненты до их инсталляции. Как мы увидим через мгновение, установка компонента в библиотеке визуальных компонентов VCL требует немного времени. Однако ошибочный компонент может разрушить Delphi и не дать ему загрузиться!

Примечание

В Delphi 3 Borland представил архитектуру пакета. Это позволяет помещать группы компонентов в отдельных библиотеках компонентов (названных пакетами), затем активизировать или деактивировать их по принципу «проект-за-проектом». Важно отладить ваши компоненты полностью, потому что компонент может разрушить среду разработки. Однако при новой архитектуре можно просто удалить пакет, вызывающий ошибки.

• Учитывайте возможность использования инструментов . разработки компонентов, предоставляемых третьими лицами. Хотя в этой книге изучается, как построить свои компоненты, помните, что написание компонентов часто утомительно и забирает много времени. Это, по существу, не визуальный процесс, а редактирование исходного текста. Однако есть некоторые коммерческие инструменты, позволяющие визуально строить компоненты, значительно упрощающие и намного ускоряющие построение компонентов даже для опытных программистов Delphi.