OOP、SRP和Checkers

Question

我刚刚启动oop，并决定编写一个检查程序的引擎。我对我构建代码的方式不太担心，我也不确定我是否没有理解oop背后的主体。我关心的是移动生成的处理，以及董事会的评估。目前，我将这两项职责划分为其他类所使用的各自的类。

我想我的问题是，这些责任应该在他们自己的类中，还是需要与AI这样的类联系在一起？但是，如果我把迁移生成和董事会评估的责任与AI这样的类联系起来，这会破坏SRP吗？

Answer 1

一个(国际象棋) Board可以保存位置数据并接受改变它的移动。它可以处理复杂的动作，如将棋子提升给皇后，或抛下。它可以验证移动和拒绝无效的移动。它可以检查攻击、死亡等情况。董事会的责任只是位置，以及如何保持正确。

给定位置，Piece可能会提供可能的移动和攻击。

AI可以采取Board并采取行动。所以，比如说，一些HumanPlayerInterface。这个界面的唯一责任就是做一个动作。当然，AI会有很多其他的移动部件；它不会改变其移动的单一责任。

Answer 2

所以，关于所有这些原则的问题是，它们不仅仅是为了使代码具有一定的审美吸引力--它们有一个实际的目的。特别是，他们关心的是使代码可维护，并使更改、扩展或替换代码的部分成为可能，而不需要太多麻烦。现在，SRP是关于让您的类“做一件事”，因为如果它们做的比“一件事”更多，那么执行这些不同事情的代码很可能以微妙的方式耦合起来，从而变得能够适应变化--也就是说很难单独更改这些部分。这意味着，仅仅通过查看您必须实现的类和行为(最多可以进行一些有教养的猜测，但这需要经验)，您就不能真正分辨出单独的责任是什么。

相反，你必须试着去理解什么是最有可能改变的，以什么方式--即使你有经验，你也很可能在第一次尝试的时候就不能做到这一点。您的代码是这个逻辑概念的软件模型(表示)，这是您正在尝试构建的系统(这个概念包括可能影响系统的所有真实世界的力量，以及它将如何改变)，而OO设计所要做的是捕捉该系统的不同部分，系统将以什么方式改变，以及如何将这些不同的组件组合在一起以适应所有这些因素。建立这样一个系统的模型总是有多种方法的；在实践中，有些方法会比其他方法更有效。是你(或你的团队)必须定义什么是“单一的事情”或“单一的责任”意味着什么，你要建立和维护的系统(以及多少工作不是“太多的麻烦”)。

尽管如此，在开发代码时，在方法级别和类级别上经常会发生变化，因为我们正在试图了解如何实现一些功能。因此，在这个级别上将SRP和其他原则先发制人地应用于我们正在解决的子问题是很好的，特别是因为在这个范围内，我们可以更好地预测我们可能希望分离的内容，或者我们以后可能希望更改实现的位置。同样，当涉及到密切相关的类时。因此，在那个层次上，由于这些或多或少都是我们所熟悉的编程问题，我们可以试着谈论SRP是否被违反，但在系统级别，它需要更深入地理解需求和系统本身，就像建模的那样。在这一级别上，同样重要的是不要预先过度设计系统。

但是，回到您的特殊情况；一般来说，将它们分开似乎是个好主意。现在，您可能有另一个类(像您的AI)使用其他类-它的职责是协调其他类所做的事情。只是不要将代码从这些其他类移动到AI类--将每一个代码保持在一个单独的位置，让每个类都完成自己的工作。从某种意义上说，这是一种责任的等级。

最后，您这样做是为了实践，目的是试图理解OOP原则，这一方面意味着您有一些自由探索，但另一方面，您将不会收到客户端的更改请求和错误报告，这将最终测试您的设计选择是否合适。所以试着用某种方式来弥补这一点。拿出你目前的设计，并研究它。当您以某种方式设计类时，总是需要某种权衡:可维护性与复杂性、性能与清晰度、模块化(在某些方面)与僵化的结构，等等。试着了解代码的哪些部分变得更容易更改，哪些部分变得更难更改。尝试更改实现以测试您的理解是否正确。然后试着想出一个不同的设计并研究它。什么改变了？你得到了什么，你失去了什么？这将帮助您理解SRP和其他原则背后的推理，这才是真正重要的。