Различия

Показаны различия между двумя версиями страницы.

--- bbextendnohost [2013/12/20 22:14]
kpmy добавил подпись, добавил результаты
+++ bbextendnohost [2013/12/21 01:05]
kpmy [Что требуется?]
@@ Строка 1: / Строка 1: @@
 ====== Метод расширения абстракций System ======
 ===== Предпосылки =====
-Системный слой BlackBox представлен набором абстрактных интерфейсов, отвечающих за те или иные функции, доступные компонентам. Эти абстракции представляют собой минимально необходимые возможности для полноценной работы, а значит, их интерфейс не может содержать особенностей платформы, так как это приведет к "протеканию" абстракции.
+Системный слой BlackBox представлен набором абстрактных интерфейсов, отвечающих за те или иные функции, доступные компонентам. Эти абстракции представляют собой минимально необходимые возможности для полноценной работы. В текущей версии интерфейсы подобраны так, что являются платформо-независимыми.
+А при дальнейшем расширении абстракций необходимо учитывать, что платформо-зависимые интерфейсы могут привести к "протеканию" абстракции.
 На примере простой абстракции местоположение файла Files.Locator (далее **локатор**) рассмотрим возможные варианты решения.
@@ Строка 12: / Строка 13: @@
 В большинстве случаев реализация локатора содержит указание на физическую папку на диске компьютера или в сети, и путь к такой папке представлен [[http://ru.wikipedia.org/wiki/%D0%9F%D1%83%D1%82%D1%8C_%D0%BA_%D1%84%D0%B0%D0%B9%D0%BB%D1%83|текстовой строкой]] в определенном формате, специфичном для ОС.
-Однако расширяемый интерфейс локатора позволяет реализовать местоположение файла, у которого отсутствует текстовая строка. Следовательно, абстрактный интерфейс получения полного текстового пути к файлу является слишком конкретным и ограничивает применение локатора.
+Однако расширяемый интерфейс локатора позволяет реализовать местоположение файла, которое не поддерживает выражение в виде строки. Следовательно, абстрактный интерфейс получения полного текстового пути к файлу является слишком конкретным и ограничивает применение локатора.
 Поэтому в Files.Locator подобная возможность отсутствует.
@@ Строка 19: / Строка 20: @@
 ===== Что требуется? =====
-Расширить возможности базового типа Files.Locator в ряде задач при сохранении неизменности интерфейса Files.Locator, сохранении возможности работы с альтернативными реализациями абстракции локатора, а так же минимизация платформо-зависимости прикладного компонента.
+Расширить возможности объекта базового типа Files.Locator в ряде задач при сохранении неизменности интерфейса Files.Locator, сохранение возможности работы с альтернативными реализациями локатора, а так же минимизация платформо-зависимости прикладного компонента.
 ===== Варианты решения =====
@@ Строка 51: / Строка 52: @@
 Таким образом, описав сообщение GetPathStringMsg мы получаем возможность запросить у локатора текстовый путь.
 Также подобные протоколы могут быть описаны в сторонних компонентах. Такие протоколы могут иметь разную детализацию аспектов платформы, тем самым позволяя разработчику гибко регулировать платформо-зависимость своего прикладного компонента.
+<code>VAR loc: Files.Locator; ober: OberFiles.Locator; gpm: OberProtocol.GetPathStringMsg;
+BEGIN
+	loc:=Files.dir.This('');
+	ober:=OberFiles.GuardLoc(loc);
+	IF ober#NIL THEN
+		ober.HandleMsg(gpm);
+	ELSE Log.String('данный тип фс ещё не поддерживается'); Log.Ln; END;
+	IF gpm.path#NIL THEN Log.String(gpm.path$); Log.Ln END;
+END;</code>
 Но само наличие таких протоколов не гарантирует, что реализация локатора их поддерживает, и это понятно, ведь сообщения это способ ослабления связности компонентов. Однако, в интересах разработчиков реализаций абстрактных интерфейсов поддерживать наибольшее количество протоколов. Такие реализации смогут сообщать клиентам о поддерживаемых протоколах.
 ===== Результаты =====
-Реализовав описанный способ расширения мы решили проблему наращивания функциональности локатора без изменения базового типа, избежав проблему появления хрупкого базового класса с помощью параметрического полиморфизма.
+Реализовав описанный способ расширения мы решили проблему наращивания функциональности локатора без изменения базового типа, избежав проблему появления хрупкого базового класса с помощью параметрического полиморфизма, а платформо-зависимость клиентских модулей может регулироваться посредством выбора нужного протокола.
 Таким образом, подсистема с набором подобных уточняющих абстракций, размещенная в общеупотребимой (а возможно и стандартной для сборки BlackBox) подсистеме сможет обеспечить развитие возможностей с сохранением обратной совместимости компонентов и интерфейсов.
+===== Пример использования =====
+Прототип реализации для эталона BlackBox размещен в подсистеме [[https://bitbucket.org/akastargazer/bb.open/src|Sith]].
  --- //[[petryxa.clever@gmail.com|Кушнир П. М.]] 2013/12/20 21:34//

Инструменты пользователя

Инструменты сайта

Различия

Инструменты страницы