Разработка повторно используемых компонентов

Разработка идеального компонента для повторного использования должна быть процессом (основанным на опыте и знаниях о проблемах повторного использования) создания обобщенных компонентов, которые можно адаптировать для разных вариантов их использования.

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

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

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

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

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

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

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