| Предыдущая версия справа и слева
Предыдущая версия
Следующая версия
|
Предыдущая версия
Следующая версия
Следующая версия справа и слева
|
bb:nohost [2016/04/03 12:23]
prospero78 [Понятие компонента] |
bb:nohost [2016/04/06 20:15]
prospero78 [Устранение зависимостей от подсистемы Host] |
| | |
| ==== Понятие компонента ==== | ==== Понятие компонента ==== |
| **Компонент** с точки зрения каркаса является совокупностью скомпилированных модулей. Модули могут использовать возможности других модулей, таким образом появляется **зависимость** (обозначена стрелкой по направлению от зависимого модуля к необходимому). FIXME ( А картинка где? Ссылка ведёт на ДропБокс) | **Компонент** с точки зрения каркаса является совокупностью скомпилированных модулей. Модули могут использовать возможности других модулей, таким образом появляется //зависимость// (обозначена стрелкой по направлению от зависимого модуля к необходимому). FIXME ( А картинка где? Ссылка ведёт на ДропБокс) |
| |
| Компоненты можно разделить на две группы: | Компоненты можно разделить на две группы: |
| ==== Системный слой ==== | ==== Системный слой ==== |
| Рассмотрим устройство системного слоя в [эталоне](http://oberoncore.ru/blackbox/oberoncore_official_position) **BlackBox**. | Рассмотрим устройство системного слоя в [эталоне](http://oberoncore.ru/blackbox/oberoncore_official_position) **BlackBox**. |
| Основой системы является модуль *Kernel*, который реализует поддержку //этапа выполнения// для приложений **BlackBox** (см. [документацию](http://oberoncore.ru/library/ermakov_vnutrennij_interfejs_kernel) *Kernel*). | Основой системы является модуль *Kernel*, который реализует поддержку //этапа выполнения// для приложений **BlackBox** (см. [документацию](http://oberoncore.ru/library/ermakov_vnutrennij_interfejs_kernel) ''Kernel''). |
| Модуль *Kernel* использует возможности операционной системы (на рисунке эта зависимость обозначена красной стрелкой). | Модуль ''Kernel'' использует возможности операционной системы (на рисунке эта зависимость обозначена красной стрелкой). |
| Для работы клиентских (прикладных) модулей необходимы базовые //абстракции// файловой системы, оконной системы, отображений, контейнеров, диалогов и т. п. В эталоне эти //абстракции// собраны в подсистеме *System* (см. рис.), часть реализаций которых платформо-независима, а часть платформо-зависима. Платформо-независимые реализации *System* содержатся в подсистеме *Std*. В то же время, в подсистеме *Std* есть такие абстракции, которым тоже необходима платформо-зависимая реализация (например, элементы управления и диалоговые окна). Платформо-зависимые реализации *System* и *Std* содержатся в подсистеме *Host*. | Для работы клиентских (прикладных) модулей необходимы базовые //абстракции// файловой системы, оконной системы, отображений, контейнеров, диалогов и т. п. В эталоне эти //абстракции// собраны в подсистеме ''System'' (см. рис.), часть реализаций которых платформо-независима, а часть платформо-зависима. Платформо-независимые реализации ''System'' содержатся в подсистеме ''Std''. В то же время, в подсистеме ''Std'' есть такие абстракции, которым тоже необходима платформо-зависимая реализация (например, элементы управления и диалоговые окна). Платформо-зависимые реализации ''System'' и ''Std'' содержатся в подсистеме ''Host''. |
| |
| Разделение *System* на абстрактный интерфейс и платформо-зависимую реализацию позволяет добиться //герметичности// платформо-независимой части //системного слоя//. Герметичность позволяет заменять платформо-зависимые системные модули без модификации клиентских модулей. | Разделение ''System'' на абстрактный интерфейс и платформо-зависимую реализацию позволяет добиться //герметичности// платформо-независимой части //системного слоя//. Герметичность позволяет заменять платформо-зависимые системные модули без модификации клиентских модулей. |
| |
| //Герметичность// здесь понимается как отсутствие [[http://www.joelonsoftware.com/articles/LeakyAbstractions.html|протечек абстракций]] системного и прикладного слоя. | //Герметичность// здесь понимается как отсутствие [[http://www.joelonsoftware.com/articles/LeakyAbstractions.html|протечек абстракций]] системного и прикладного слоя. |
| |
| В идеале, абстракции системного слоя должны удовлетворять всем потребностям прикладного слоя. Но, по историческим причинам, в эталонной сборке **BlackBox** системные абстракции не идеальны и поэтому имеются **нарушения герметичности** системного слоя (также обозначенные на рисунке красными стрелками), что приводит к прямой или косвенной (строковые константы и т.д.) зависимости прикладных модулей от операционной системы. | В идеале, абстракции системного слоя должны удовлетворять всем потребностям прикладного слоя. Но, по историческим причинам, в эталонной сборке **BlackBox** системные абстракции не идеальны и поэтому имеются **нарушения герметичности** системного слоя (также обозначенные на рисунке красными стрелками) FIXME , что приводит к прямой или косвенной (строковые константы и т. д.) зависимости прикладных модулей от операционной системы. |
| |
| # Решение проблемы нарушения герметичности # | # Решение проблемы нарушения герметичности # |
| ## Модификация модуля Kernel ## | ## Модификация модуля Kernel ## |
| |
| На схеме показаны зависимости прикладного и системного слоя от модуля *Kernel*. | На схеме показаны зависимости прикладного и системного слоя от модуля ''Kernel''. |
| |
| Эти зависимости не позволяют нам произвести безопасную замену модуля *Kernel*, например, при замене операционной системы. Безопасность, в данном случае, это //соблюдение контрактов интерфейса//. Текущий интерфейс модуля *Kernel* явно зависит от модуля *WinApi*, что предполагает изменение этого интерфейса (а значит контрактов), при смене ОС. Это и есть нарушение герметичности системного слоя **БлэкБокса**. | Эти зависимости не позволяют нам произвести безопасную замену модуля ''Kernel'', например, при замене операционной системы. Безопасность, в данном случае, это //соблюдение контрактов интерфейса//. Текущий интерфейс модуля ''Kernel'' явно зависит от модуля ''WinApi'', что предполагает изменение этого интерфейса (а значит контрактов), при смене ОС. Это и есть нарушение герметичности системного слоя **БлэкБокса**. |
| |
| В целях устранения данного нарушения герметичности предлагается разделение интерфейса модуля *Kernel* на платформо-независимую (условно: Pascal_kernel) и платформо-зависимую части(условно: Win32kernel, Win64kernel, Lin32kernel, Lin64kernel и т. д.). | В целях устранения данного нарушения герметичности предлагается разделение интерфейса модуля ''Kernel'' на платформо-независимую (условно: ''(Kernel)Pascal'') и платформо-зависимую части(условно: ''(Kernel)Win32'', ''(Kernel)Win64'', ''(Kernel)Lin32'', ''(Kernel)Lin64'' и т. д.). |
| |
| Плюсом данного решения является **полное изолирование** клиентских модулей от платформы. | Плюсом данного решения является **полное изолирование** клиентских модулей от платформы. |
| |
| Минусом является то, что модуль *Kernel* это //специфический// системный модуль: **невозможно** наверняка предугадать абстракции, которые могут понадобиться клиентам. А необходимые для работы каркаса низкоуровневые функции *Kernel* (ассемблерный код, прямая работа с памятью) не могут быть реализованы (или хотя бы представлены в виде абстракций) платформо-независимо. | Минусом является то, что модуль ''Kernel'' это //специфический// системный модуль: **невозможно** наверняка предугадать абстракции, которые могут понадобиться клиентам. А необходимые для работы каркаса низкоуровневые функции ''Kernel'' (ассемблерный код, прямая работа с памятью) не могут быть реализованы (или хотя бы представлены в виде абстракций) платформо-независимо. |
| |
| Решением данной проблемы может стать использование специальных соглашений и разделение платформо-зависимых компонентов на абстракции и платформо-зависимые реализации (Host-компоненты)(( --- //[[prospero.78.su@gmail.com|Валерий Шипков]] 2016/04/03 12:16// Имхо, *Kernel* должен _гарантированно_ использовать только те абстракции и реализации, которые будут доступны везде )). | Решением данной проблемы может стать использование специальных соглашений и разделение платформо-зависимых компонентов на абстракции и платформо-зависимые реализации (Host-компоненты)(( --- //[[prospero.78.su@gmail.com|Валерий Шипков]] 2016/04/03 12:16// Имхо, ''Kernel'' должен _гарантированно_ использовать только те абстракции и реализации, которые будут доступны везде )). |
| |
| ## Устранение зависимостей от подсистемы Host ## | ## Устранение зависимостей от подсистемы Host ## |
| |
| Модули подсистем *Std* и *System*, входящие в эталон BlackBox, по большей части являются платформо-независимыми. Однако, в некоторых местах обнаруживаются прямые (импорт) или косвенные (через строковые константы/ресурсы, отображения на формах и т.д.) зависимости от подсистемы *Host*. | Модули подсистем ''Std'' и ''System'', входящие в эталон **BlackBox**, по большей части являются платформо-независимыми. Однако, в некоторых местах обнаруживаются прямые (импорт) или косвенные (через строковые константы/ресурсы, отображения на формах и т. д.) зависимости от подсистемы ''Host''. |
| |
| Эти зависимости в той или иной степени обеспечивают функционирование эталона, при этом ухудшая его платформо-независимость. Так как функциональность *Host* нужна системному слою, то необходимо сохранить её, но уже с использованием герметичных решений. | Эти зависимости в той или иной степени обеспечивают функционирование эталона, при этом ухудшая его платформо-независимость. Так как функциональность ''Host'' нужна системному слою, то необходимо сохранить её, но уже с использованием герметичных решений. |
| |
| Для устранения зависимости подсистемы *Std* от *Host* введём ряд дополнительных абстракций в подсистему *System*, которые заместят необходимые ранее зависимости. А подсистему *Host* дополним подсистемой *PascalHost*, в которой находятся реализации этих абстракций(Win32Host, Win64Host, Lin32Host, Lin64Host). | Для устранения зависимости подсистемы ''Std'' от ''Host'' введём ряд дополнительных абстракций в подсистему ''System'', которые заместят необходимые ранее зависимости. А подсистему ''Host'' дополним подсистемой ''(Host)Pascal'', в которой находятся реализации этих абстракций( ''(Host)Win32'', ''(Host)Win64'', ''(Host)Lin32'', ''(Host)Lin64''). |
| |
| Некоторые прямые и косвенные зависимости (формы, строковые ресурсы) подсистем *Std* и *System* могут быть перемещены в подсистему *Host* целиком, или частично. Например, модуль *StdMenuTool* или содержимое меню *(System)Menus*, которое состоит из текстовых команд зависящих от подсистемы *Host*. Такие команды могут быть размещены в меню *(Host)Menus*. | Некоторые прямые и косвенные зависимости (формы, строковые ресурсы) подсистем ''Std'' и ''System'' могут быть перемещены в подсистему ''Host'' целиком, или частично. Например, модуль ''StdMenuTool'' или содержимое меню ''(System)Menus'', которое состоит из текстовых команд зависящих от подсистемы ''Host''. Такие команды могут быть размещены в меню ''(Host)Menus''. |
| |
| Прикладные компоненты с зависимостями от *Host*, должны быть аналогичным образом преобразованы в набор абстракций и Host-реализаций. | Прикладные компоненты с зависимостями от ''Host'', должны быть аналогичным образом преобразованы в набор абстракций и Host-реализаций. |
| |
| ---- | ---- |
