我想知道是否可以就网络井字游戏的最佳/最有利的设计模式获得您的想法和建议？
我一直在研究以下设计模式：Factory、Abstract Factory、Singleton、Prototype 和 Builder。
根据您的经验，哪个最好用，为什么？
现在，我的井字游戏是一个线程客户端/服务器游戏，可以通过套接字在互联网上玩。不过，我将以某种方式重构游戏以利用设计模式。
我正在考虑建立一个客户端/服务器架构，可用于玩许多不同类型的游戏，例如井字游戏、connect 5 等...
我应该往哪个方向走？我正在寻找一个真正能给我一些设计模式经验的方向......
谢谢！
【问题讨论】：
标签： design-patterns
不同的模式用于不同的原因。通常情况下，您会在单个应用中看到不止一种设计模式，这是一种将正确的模式用于正确的工作的情况。
例如，在一个 Web 应用程序中，我可能将单例模式用于设置类，将工厂类用于数据库连接。单例确保我只有设置对象，工厂类负责为我提供适合我的环境的数据库适配器。
【讨论】：
您命名的模式不是架构模式，但作为扩展模式，构建器模式可能非常适合使用通用基础架构来服务不同游戏的多游戏服务器。在这里，您的构建器将根据（抽象）“游戏板”、“游戏规则”、“游戏引擎”等组装特定的游戏引擎。
【讨论】：
由于您希望为许多不同的游戏设置架构，因此这是尝试实现工厂和/或抽象工厂模式的好地方。这样，当您请求一个新的游戏实例时，您可以通过从工厂请求一个新的游戏实例来将您的代码与正在启动的特定游戏解耦。
我想提醒您，设计模式不会自动使您的代码“更好”。不要误会我的意思，设计模式对于复杂系统和创建可重用、可扩展的代码库（更不用说创建更好的组织和清晰度）非常有用，但只有在有意义时才应该应用它们。尝试在您的代码中随处应用设计模式很可能会导致实现不适合您的特定问题或在复杂性方面过于矫枉过正的模式。
编写工厂以在 hello world 应用程序 clear 中生成 hello world 字符串的实例显然是矫枉过正。编写工厂以在大型企业客户端/服务器架构中分发预配置的套接字连接是更自然的选择。您的应用程序可能处于中间位置，由您决定设计模式是否会对您的特定项目有所帮助。
【讨论】：
设计模式只是一种设计方式的名称。井字游戏可以使用所有设计模式，也可以不使用它们。它们只是如何做某件事的一种模式。
你想重构你的代码，这很公平，但不要这样做，因为你想要更多的设计模式。这样做是因为您想清理代码，使其更通用，并可能将其扩展到其他游戏。
要获得关于使用哪种设计模式的好答案，请举一个具体的例子：
问。我应该如何限制 network_handler 到一个实例？ - 一种。 使用单例
否则你可以找到一个包含几乎所有设计模式的理由。
【讨论】：
警告：我讨厌人们使用“设计模式”作为目标。设计好的代码，如果你所做的看起来像 DP，使用 DP 来帮助你改进代码。但不要一开始就说“我想使用 Striking Crane Pattern 编写程序”。这就是本末倒置。 DP应该从你的设计中出现。他们不应该推动设计。
结束警告
您已经在使用设计模式。 DP 只是编程中常用的“模式”的行话。您首先应该问自己的是“我如何识别我编写的网络游戏中的设计模式？”
之后，您就可以放心继续前进了。要拥有多个游戏，您可能希望使用抽象工厂模式来处理您的游戏。服务器调用工厂来获取一个知道如何玩所选游戏的游戏对象。
【讨论】：