c++ - 如何降低库中的复杂性而不增加其他地方的复杂性?

标签 c++ design-patterns

我的任务是维护和更新一个库,该库允许计算机在硬件设备上发送命令,然后接收其响应。目前,代码的设置方式是设备可以接收的每个可能的命令都是通过其自己的函数发送的。代码重复无处不在; DRY 倡导者最可怕的噩梦。

显然还有很多改进的机会。问题是每个命令都有不同的有效负载。目前,作为有效负载的数据以参数的形式传递给每个命令函数。如果不将复杂性提高到调用库的水平,就很难整合功能。

当从设备收到响应时,其数据被放入专门负责保存此数据的类的对象中,它们不执行任何其他操作。有数百个类可以执行此操作。然后应用层使用这些对象来访问返回的数据。

我的目标:

彻底减少代码重复

在应用层保持相似的复杂性

让添加新命令变得更加容易

我的想法:

有一个发送命令的函数和一个接收命令的函数(当检测到设备的响应时,会自动调用接收函数)。有一个结构体保存所有命令/响应数据,这些数据将传递给发送函数并由接收函数返回。由于每个命令都有一个相应的枚举值,因此有一个 switch 语句来设置要发送的任何命令特定数据。

我的想法是最好的实现方式吗?我可以在这里使用设计模式吗?我看了又看,但似乎没有什么能满足我的需求。

提前致谢! (如果需要澄清,请告诉我)

最佳答案

这让我想起了 REST 与 SOA 的争论,尽管物理规模较小。

如果我理解正确的话,现在你有这样的电话

device->DoThing();
device->DoOtherThing();

有时我会收到类似的回调

callback->DoneThing(ThingResult&);
callback->DoneOtherTHing(OtherThingResult&)

我认为用户是这里的关键组成部分。当前的图书馆用户是否喜欢其设计级别的界面?接口(interface)是否一致,即使它很大?

你似乎想求婚

device->Do(ThingAndOtherThingParameters&)
callback->Done(ThingAndOtherThingResult&)

这样就有一个包含更复杂数据的入口点。

从库用户角度来看,缺点可能是,现在我必须使用手动 switch() 或其他类型语句来告诉到底发生了什么。虽然调度到适当的结果回调过去是为我完成的,但现在你已经把它变成了库用户的负担。

除非这为我作为用户带来了一定程度的灵活性,否则我作为用户希望我会认为这是倒退。

对于您作为实现者而言,一个建议是在内部使用通用形式,然后在外部提供这两个接口(interface)。也许旧的特定界面甚至可以以某种方式自动生成。

祝你好运。

关于c++ - 如何降低库中的复杂性而不增加其他地方的复杂性?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2327498/

相关文章:

c# - 较大数据集的子集 View 的设计模式

C++:在这种情况下引用的优势是什么?

c++ - Xcode 上的 SDL2 代码设计问题

java - 从基类设置派生类成员

ruby-on-rails - 设计模式和企业设计模式有什么区别?

wpf - ViewModel 可以与 MVVM 模式中的 View 对话吗?

java - 覆盖抽象方法时的通用代码 - 设计问题

c++ - 如何在 Windows 上eekg() 超过 4GB 的文件?

c++ - 如何防止 iostreams::mapped_file_sink 创建可执行 txt 文件

c++ - 当我从虚拟基派生 D 时,为什么 VS2015 中的 sizeof(D) 增加了 8 个字节?