gpt4 book ai didi

c++ - 为 'solver' 类设计通用处理程序

转载 作者:行者123 更新时间:2023-11-28 05:52:29 24 4
gpt4 key购买 nike

“问题”在标题中不应该是问题的情况。

我想为一组问题(类 Problem 的所有子项)实现一个求解器(类 Solver),这些问题或多或少共享同一组方法。我目前的设计是这样的:

solver.h :

template<class P>
class Solver{
public:
P* p;
Solver(P* problem) : p(problem) {}
void justDoIt(){
p->step1();
p->step2();
p->step3();
p->step4();
p->step5();
}
}

main.cpp : #include "solver.h"

class A {
public:
void step1() {}
void step2() {}
void step3() {}
void step4() {}
void step5() {}
};

class B: public A {
public:
void step2() {}
void step4() {}
};

class C: public A {
public:
void step3() {}
void step4() {}
void step5() {}
};

int main(){
B b;
C c;
Solver<B> sb(&b);
Solver<C> sc(&c);
sb.justDoIt();
sc.justDoIt();
return 0;
}

如果我想为一个新的问题类型扩展求解器,比如 C,它

  1. step1() 中什么都不做;
  2. step2.5()step2() 之间和 step3()

现在打电话 C c; Solver<C> sc(&c); c.justDoIt() , 我需要修改 A , BSolver::justDoIt()首先。

是否有一个可扩展的设计界面,为 A 添加新问题类型(Solver 的所有子项)? ?

PS:目前我要修改的代码库有47种问题都使用相同的Solver类(class)。最小的变化是首选。

我怎样才能做得更好?

最佳答案

至少对我来说,这个设计看起来像是一团糟(请原谅技术术语)。

现在,SolverProblem 的内部结构了如指掌。此外,Solver 似乎也无法在不了解Problem 内部结构的情况下完成其工作。

至少在我看来,您所说的 Solver::justDoIt() 应该是 Problem::operator()。如果 许多 问题使用 step1()step5() 正如您在 中所示>Solver,您可以在 Problem 本身中默认提供该实现,然后那些需要覆盖的将提供自己的实现:

class Problem { 
protected:
virtual void step1() {}
// ...
virtual void step5() {}
public:
virtual void operator()() {
step1();
step2();
step3();
step4();
step5();
}
};

class B : public Problem {
protected:
void step2() {}
void step4() {}
};

class C : public Problem {
protected:
virtual void step3() {}
virtual void step4() {}
virtual void step5() {}
};

然后主要看起来像这样:

int main() { 
B b;
C c;

b();
c();
}

或者,如果您喜欢更短的代码:

int main() { 
B()();
C()();
}

这会为每种类型创建一个临时对象,然后对该临时对象调用 operator()。我不是特别喜欢它,但有些人认为它很棒。

关于c++ - 为 'solver' 类设计通用处理程序,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34937204/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com