Как набор функций в глобальном пространстве имен может вписаться в объектно-ориентированный дизайн?

Question

Программное обеспечение, производимое моей компанией, имеет несколько уровней и разбито на два проекта.«Внутренний уровень» является уровнем HAL и напрямую взаимодействует с драйвером для производимого нами оборудования.Это в проекте Visual Studio под названием "xxxHAL".Этот проект встроен в статическую библиотеку.Другие слои вместе образуют клиентский API.Эти «другие слои» находятся в своем отдельном проекте VS и статически связывают файл HAL lib с самого начала.Они встроены в DLL, которую мы распространяем, чтобы клиенты могли создавать свое собственное программное обеспечение.

Мои вопросы:

• Какова мотивация для разделения функций HAL на их собственныестатическая библиотека?

• Зачем помещать все эти функции HAL в глобальное пространство имен?Как это вписывается в парадигму ООП?

Весь набор из двух проектов - это недавний редизайн старого API с нуля, и он был построен очень методично.Дизайн API очень объектно-ориентирован, и, на мой взгляд, выглядит достаточно хорошо разработанным.Для конечного пользователя все довольно просто и понятно, поэтому я могу понять мотивацию для создания программного обеспечения на стороне API таким образом.Я думаю, что в основном я чувствую, что если бы я пошел и разработал программное обеспечение с нуля, я бы выбрал другой подход.Есть мысли?

Answer 1

Какова мотивация для разделения функций HAL на их собственную статическую библиотеку?

Название говорит само за себя Уровень аппаратной абстракции .
Он разъединяетдругие программные компоненты в вашем проекте от Аппаратного обеспечения.
Эта слабая связь гарантирует легкую переносимость между различными Аппаратными платформами.
Кроме того, он абстрагируется от того, что «другие слои» вашего программного обеспечения остаются отвлеченными от любых изменений исходного кода в исходном коде Аппаратного обеспечения.,