Это старая версия документа!
Системный слой BlackBox представлен набором абстрактных интерфейсов, отвечающих за те или иные функции, доступные компонентам. Эти абстракции представляют собой минимально необходимые возможности для полноценной работы, а значит, их интерфейс не может содержать особенностей платформы, так как это приведет к «протеканию» абстракции.
На примере простой абстракции местоположение файла Files.Locator (далее локатор) рассмотрим возможные варианты решения.
Русская документация по BlackBox
Файловый локатор представляет папку в файловой системе.
Локаторы используются в Блэкбоксе и иногда в командах, которые работают с файлами, не принадлежащими Блэкбоксу.
Таким образом, локатор представлен объектом в памяти. В большинстве случаев реализация локатора содержит указание на физическую папку на диске компьютера или в сети, и путь к такой папке представлен текстовой строкой в определенном формате, специфичном для ОС.
Однако расширяемый интерфейс локатора позволяет реализовать местоположение файла, у которого отсутствует текстовая строка. Следовательно, абстрактный интерфейс получения полного текстового пути к файлу является слишком конкретным и ограничивает применение локатора.
Поэтому в Files.Locator подобная возможность отсутствует.
И все же, при написании прикладных компонентов могут возникать задачи которые требуют доступ к строке адреса файла на диске, отображение пользователю реального пути к выбранному файлу, сохранение адреса конкретного файла в реестре, и так далее. Таким образом, возможностей интерфейса локатора становится недостаточно, а прикладной компонент неизбежно становится более платформо-зависимым.
Расширить возможности базового типа Files.Locator в ряде задач при сохранении неизменности интерфейса Files.Locator, сохранении возможности работы с альтернативными реализациями абстракции локатора, а так же минимизация платформо-зависимости прикладного компонента.
Наиболее очевидный способ: изменение алгоритма компонента. Действительно, в ряде случаев возможно изменение алгоритмов работы таким образом, что доступ к строке станет не нужен, а базового интерфейса локатора будет достаточно.
Наиболее простой способ, так как мы точно знаем, какие возможности может дать конкретная реализация локатора. Полная платформо-зависимость компонента становится платой за простоту.
После применения к платформо-зависимому компоненту метод герметизации получится гибкая связка компонента и хост-компонента, который для той или иной платформы будет предоставляеть реализации интерфейса получения строки пути. Удобное и быстрое решение. Однако, при развитии системы компонентов появляется вероятность дублирования реализации хост-компонента для разных прикладных компонентов, а в масштабе сообщества - появление огромного количества несовместимых хост-компонентов с пересекающимися возможностями.