"State pattern" 对比 "one member function per state"？
"State pattern" vs "one member function per state"?
我的 class 有 3 个状态。在每个状态下，它都会做一些工作，然后转到其他状态，或者保持在相同的状态（在 95% 或更多的情况下，它会保持在相同的状态）。我可以实现状态模式（我假设你知道）。我非常喜欢的替代方案是：
我每个状态都有一个成员函数，还有一个指向成员函数的指针，它指向当前状态函数。当处于一个状态我想进入另一个状态时，我只需将该函数指针指向另一个状态函数。 （也许这不完全等同于状态模式，但在我的例子中它工作正常）。
我认为这两种方式几乎相同。
所以，我的问题是：
- 哪种解决方案更好（取决于什么）？
- 是否值得为每个州声明一个 class（只有一个功能）？我认为那是人为的。
- 性能怎么样？创建状态 class 的新对象（在状态模式的情况下）不会带来轻微的开销吗？ （当然状态 classes 不应该有成员，但无论如何它应该花费一些）
这取决于您是否需要访问对象的私有成员。如果不是，那么 class 之外的实现会将您的代码分解成更小的片段，因此可能更可取（但这不是 objective ：两种解决方案各有利弊）。
不是必须的，只是加了一层抽象，松耦合。使用接口，您可以更改每个实现而不影响其他实现（例如添加 class 字段...）
没关系，分配一个新的空 class 或调用一个函数的开销是一样的。
您并没有真正提到您的程序 运行 所受的约束，因此很难具体评论一种实现相对于另一种实现的开销，因此我将只对代码可维护性发表评论。
我个人认为，除非您的状态机非常简单并且会保持简单，否则为每个状态声明一个 class 会更易于维护、可扩展和可读。一个好的经验法则可能是，如果您不能查看 class 中的代码并将整个画面记在脑海中，那么您的 class 可能做得太多了。您在为每个状态声明 class 时付出的少量开销可能非常值得您通过编写模块化代码（或最终维护它的任何其他人）获得的生产力提升。我遇到过太多 'uber' classes 本质上是一个大的（很难维护）状态机，可能开始时只是一个简单的状态机，否则就不推荐了。
SOLID 首字母缩略词的 'S' 和 'O' 部分（https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) 总是值得记住的好东西。
我的 class 有 3 个状态。在每个状态下，它都会做一些工作，然后转到其他状态，或者保持在相同的状态（在 95% 或更多的情况下，它会保持在相同的状态）。我可以实现状态模式（我假设你知道）。我非常喜欢的替代方案是：
我每个状态都有一个成员函数，还有一个指向成员函数的指针，它指向当前状态函数。当处于一个状态我想进入另一个状态时，我只需将该函数指针指向另一个状态函数。 （也许这不完全等同于状态模式，但在我的例子中它工作正常）。
我认为这两种方式几乎相同。
所以，我的问题是：
- 哪种解决方案更好（取决于什么）？
- 是否值得为每个州声明一个 class（只有一个功能）？我认为那是人为的。
- 性能怎么样？创建状态 class 的新对象（在状态模式的情况下）不会带来轻微的开销吗？ （当然状态 classes 不应该有成员，但无论如何它应该花费一些）
这取决于您是否需要访问对象的私有成员。如果不是，那么 class 之外的实现会将您的代码分解成更小的片段，因此可能更可取（但这不是 objective ：两种解决方案各有利弊）。
不是必须的，只是加了一层抽象，松耦合。使用接口，您可以更改每个实现而不影响其他实现（例如添加 class 字段...）
没关系，分配一个新的空 class 或调用一个函数的开销是一样的。
您并没有真正提到您的程序 运行 所受的约束，因此很难具体评论一种实现相对于另一种实现的开销，因此我将只对代码可维护性发表评论。
我个人认为，除非您的状态机非常简单并且会保持简单，否则为每个状态声明一个 class 会更易于维护、可扩展和可读。一个好的经验法则可能是，如果您不能查看 class 中的代码并将整个画面记在脑海中，那么您的 class 可能做得太多了。您在为每个状态声明 class 时付出的少量开销可能非常值得您通过编写模块化代码（或最终维护它的任何其他人）获得的生产力提升。我遇到过太多 'uber' classes 本质上是一个大的（很难维护）状态机，可能开始时只是一个简单的状态机，否则就不推荐了。
SOLID 首字母缩略词的 'S' 和 'O' 部分（https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) 总是值得记住的好东西。