“告诉，不要询问”原则
内容提要
“告诉，不要询问”是面向对象编程中的一个重要设计原则，强调代码应以请求所需行为的方式编写，而不是直接查询其他对象的状态。通过这种方式，对象的内部状态被封装，不会暴露给外部，对象之间的耦合度降低，从而提高了可维护性和可重用性。本文通过游戏开发实例来解释这一原则，并介绍正确的方法及其带来的好处。马丁·福勒强调，在应用“告诉，不要询问”原则时，灵活应对具体情况很重要，同时要考虑对象的封装和耦合度，并兼顾代码的可读性和可维护性。
延伸解读
原则的核心：封装与行为请求
“告诉，不要询问”原则的核心在于将对象的状态封装在内部，外部对象不应直接查询其状态，而应通过请求行为来间接影响状态。例如，在游戏开发中，Player类不应检查Weapon的弹药数量，而应直接调用Weapon的Fire方法。这样，Weapon的内部状态（如弹药数）被隐藏，外部对象无需了解其细节，从而降低了耦合度，提高了代码的可维护性和可重用性。
违反原则的代价：高耦合与封装破坏
当外部对象直接查询另一个对象的状态并根据该状态做出决策时，会导致类之间的高耦合。例如，如果Player类检查Weapon的弹药数量后再决定是否开火，那么Player就依赖于Weapon的内部状态。一旦Weapon的内部实现发生变化（如弹药管理逻辑改变），Player类也可能需要修改。此外，这种直接访问破坏了Weapon的封装性，使得内部状态暴露给外部，增加了代码的脆弱性和维护成本。
正确实践：行为请求与封装保持
遵循“告诉，不要询问”原则的正确做法是让对象自己管理其状态并对外提供行为方法。在游戏示例中，Weapon类内部检查弹药数量并决定是否开火，而Player类只需调用weapon.Fire()。这样，Player类无需知道Weapon的内部状态，Weapon类保持封装，对象间的交互更简洁。这种设计降低了耦合度，使得每个类可以独立变化，从而提高了系统的可维护性和可重用性。
灵活应用：马丁·福勒的提醒
马丁·福勒强调，虽然“告诉，不要询问”原则很有价值，但不应盲目严格应用。在某些情况下，直接查询对象状态可能更清晰易懂。例如，当逻辑简单或状态查询是自然表达时，过度封装可能导致代码复杂化。因此，开发者需要在封装、耦合度与代码可读性、可维护性之间权衡，根据具体场景灵活运用该原则，而不是教条地遵守。
Q&A
什么是‘告诉，不要询问’原则？
‘告诉，不要询问’是面向对象编程中的一个设计原则，强调通过请求行为而非查询状态来编写代码。
该原则如何提高代码的可维护性？
通过封装对象的内部状态，降低对象间的耦合度，从而提高代码的可维护性和可重用性。
在游戏开发中如何应用‘告诉，不要询问’原则？
在游戏开发中，角色可以直接请求武器执行攻击，而不是查询武器的状态，这样可以保持对象的封装性。
错误的实现方式会导致什么问题？
错误的实现方式会导致类之间的高耦合，破坏封装性，从而增加代码复杂性。
马丁·福勒对该原则有什么看法？
马丁·福勒强调在应用该原则时应灵活应对具体情况，兼顾代码的可读性和可维护性。
如何简化对象间的交互？
通过遵循‘告诉，不要询问’原则，直接请求行为而非查询状态，可以简化对象间的交互。
