全局命名空间中的一组函数如何适应面向对象的设计？
我公司生产的软件有好几层，分为两个项目。 “内层”是 HAL 层，直接与我们生产的硬件的驱动程序对话。这是一个名为“xxxHAL”的 Visual Studio 项目。该项目构建成静态库。其他层一起形成客户端 API。这些“其他层”位于它们自己单独的 VS 项目中，并从第一个文件静态链接 HAL lib 文件。它们构建到我们分发的 DLL 中，以便客户可以构建自己的软件。
我的问题：
将 HAL 函数分离到自己的静态库中的动机是什么？
为什么要把所有这些 HAL 函数放在全局命名空间中？这如何适应 OOP 范式？
整个两个项目集是最近对旧 API 的重新设计，并且构建得非常有条理。 API 设计非常面向对象，在我看来至少设计得相当好。对于最终用户来说，一切都非常易于使用且清晰，因此我可以理解以这种方式构建 API 用户端软件的动机。我想我主要是觉得如果我从头开始设计软件，我会采取不同的方法。有什么想法吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
将 HAL 函数分离到自己的静态库中的动机是什么？
名称说明了一切硬件抽象层。
它将项目中的其他软件组件与硬件解耦。
这种松散耦合确保了跨不同硬件平台的轻松移植性。
此外，它抽象出软件的“其他层”从硬件源代码中的任何源代码更改中抽象出来。
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.