我的任务是维护和更新一个库,该库允许计算机在硬件设备上发送命令,然后接收其响应。目前,代码的设置方式是设备可以接收的每个可能的命令都是通过其自己的函数发送的。代码重复无处不在; 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/