Code: puzzle.solver.base

Question

Code: puzzle.solver.base

Closed this issue 3 years ago · 4 comments

There is now a puzzle.solver.base class. It pretty much does nothing, but exists to define a base class with overloadable member functions. The puzzle.solver.simple class should be modified to be a sub-class of it.

Answer 1 · 2021-08-16T20:51:05.000Z

@Uio96
If using a manager for the association, should the manager also be a member variable of all puzzle solvers? If all solvers need an association mechanism, then maybe it should be a necessary element for all solvers.

Answer 2 · 2021-08-16T20:53:16.000Z

@Uio96
If using a manager for the association, should the manager also be a member variable of all puzzle solvers? If all solvers need an association mechanism, then maybe it should be a necessary element for all solvers.

Yep. I agree with this idea.

Answer 3 · 2021-08-16T22:06:45.000Z

@Uio96
OK, except that means a manager should probably have its own class hierarchy since there are many manager instance types. Mostly for testing purposes. Eventually, the full system will have one version as the go to one.

Own class hierarchy naturally means to have a namespace and be incorporated as a puzzle.manager package. You'll have to create an issue in this milestone to address that and then define a baseline class.

Will it be its own class with a member variable that does all the work so that it can be adjusted in sub-classes?
Or will it be derived from a perceiver instance with all the flexibility of a perceiver plus extra functionality that gets encoded within the derived class?

Think it through and create a new issue with your justification.

Answer 4 · 2021-08-17T03:05:10.000Z

@Uio96
OK, except that means a manager should probably have its own class hierarchy since there are many manager instance types. Mostly for testing purposes. Eventually, the full system will have one version as the go to one.

Own class hierarchy naturally means to have a namespace and be incorporated as a puzzle.manager package. You'll have to create an issue in this milestone to address that and then define a baseline class.

Will it be its own class with a member variable that does all the work so that it can be adjusted in sub-classes?
Or will it be derived from a perceiver instance with all the flexibility of a perceiver plus extra functionality that gets encoded within the derived class?

Think it through and create a new issue with your justification.

See #29 (comment)