如果您将算法表示为策略,那么您/应该/已经想到了一个非常统一的界面。您可以想象一个“AlgorithmPolicy”处理数据存储中的一些数据并返回结果的一些表示。
“如果我想象我重新设计了我的通用/面向对象的现有设计使用策略,我该如何选择最佳算法和数据结构?”
如果您的面向对象设计当前使用策略模式(另请参阅:四人帮一书),您的策略将简单地替换您使用策略的每个地方。为您设计的不同策略选择“最佳算法”只是为这些策略确定正确的概念结构/接口。(例如,如果您要使用许多不同的数据存储,请确保从它们添加/删除/获取数据的接口是统一的。在这里,考虑三个示例并找到共性会很有帮助......然后想想另一个例子并确保它符合模式。迭代直到感觉正确为止。)
你仍然会有足够的类型检查,只是感觉有点不同(你可能偶尔会遇到一些令人讨厌的编译错误。;)
测试只是为您想要涵盖的每个配置/策略组合编写一些单元测试。无论如何,您可能应该已经在编写这些测试了;主要区别在于,您将要尝试使用您指定的接口,而不是针对具体细节。
您可以根据对算法策略的验证来验证不同的存储方法。(所以,如果我有一些可以以不同方式存储的算法,我可以在 ecah 存储机制的一些测试数据上运行该算法并期望得到相同的结果。)假设你已经指定了接口正确性,你应该只需要为您添加的每个附加存储机制编写一个测试。
再说一遍:如果能有更多关于程序结构的详细信息,你需要传入哪些不同的参数等等。(这些代码中是否有任何开源/将开源?)
根据您所说,在我看来,您的复杂策略流程可能具有如下界面:
FancyDataStore.Process()
为了测试它,我会写: MockAlgorithmPolicy - 一个非常简单的算法,验证起来很简单。MockInternalStuffPolicy - 一个非常简单的内部材料策略,不会导致集成/报告任何新内容。MockStoragePolicy - 一个非常简单的存储策略,满足您的存储接口/不会引起很多问题。
编写一个测试来验证放在一起的模拟...对于您创建的每个 StoragePolicy,编写一个自动化测试来验证它:
testSomeStoragePolicy{
// has a call to:
FancyDataStore.Process<MockAlgorithmPolicy, SomeStoragePolicy, MockInternalStuff>()
// validate...
}
这应该证明 SomeStoragePolicy 按预期工作。
然后,对于您的算法,您可以编写:
testSomeAlgorithmPolicy{
FancyDataStore.process<SomeAlgorithmPolicy, MockStoragePolicy, MockInternalStuff>();
///Validate.
}
这样,您基本上为每个最终编写的策略编写 1 个测试(这似乎可行且不太荒谬)此外,您始终可以添加额外的单元测试以涵盖可能随着时间推移而出现的其他细微集成。
如果您正在寻找有关此主题的好书,我建议您阅读“现代 C++ 编程”;它为 C++ 中的策略驱动设计提供了很好的入门知识。