How can a set of functions in the global namespace fit into an object oriented design?

Question

The software produced by my company has several layers and is broken into two projects. The "inner layer" is a HAL layer and talks directly to the driver for the hardware we produce. This is in a Visual Studio project called "xxxHAL". This project builds into a static library. The other layers together form a client-API. These "other layers" are in their own separate VS project and statically link the HAL lib file from the first. They build into a DLL that we distribute so that clients can build their own software.

My questions:

• What is the motivation for separating the HAL functions into their own static library?

• Why put all these HAL functions in the global namespace? How does this fit into the OOP paradigm?

The entire two-project set is a recent redesign of an older API from the ground up and was built very methodically. The API design is very object-oriented and to my eyes appears at least pretty well designed. For the end-user, things are pretty easy to use and clear, so I can understand the motivation for building the API-user side software this way. I guess I'm mainly feeling that if I had gone and designed the software from the ground up, I would have taken a different approach. Any thoughts?

Answer 1

What is the motivation for separating the HAL functions into their own static library?

The name says it all Hardware Abstraction Layer.
It decouples other software components in your project from the Hardware.
This loose coupling ensures easy portability across different Hardware platforms.
Also, It abstracts that "other layers" of your software stay abstracted from any source code changes in Hardware source code.