Rule of Three
在重构时，”Rule of Three”是一个指导原则，它建议在你第三次遇到相似的代码结构时才进行抽象或重构。这条规则的基本思想是，只有当相同的代码模式至少出现三次时，才值得将其抽象成一个共用的构造，比如一个函数、类或者模块。这个原则旨在帮助开发者在“不重复自己”（DRY原则）和“过早优化是万恶之源”之间找到平衡。
Rule of Three的应用
- 避免过早抽象：过早地对代码进行抽象可能导致设计过于复杂，难以理解和维护。在你完全理解需求之前，试图进行抽象可能会限制代码的灵活性和适应性。Rule of Three鼓励开发者在明确看到重复模式之后才进行抽象，这时候对需求和解决方案的理解更加成熟。
- 提升代码复用性：当相似的代码结构出现三次或以上时，通过重构来消除重复，不仅可以减少代码量，还能提升代码的可维护性和可扩展性。一个共用的构造使得未来的修改更集中，减少了修改引起的错误。
- 简化后期维护：通过延迟抽象直到有充分的理由（即相似的代码出现三次），可以确保重构工作对于整体架构和设计是有益的。这样做有助于简化后期的维护工作，因为抽象是基于实际需求而非假设进行的。
实践中的考虑
- 情境灵活性：尽管Rule of Three是一个有用的指导原则，但它不是绝对的法则。在实际开发过程中，是否遵循这一原则应根据具体情况灵活考虑。例如，如果开发者非常确信某种模式会频繁重复，那么在第二次遇到时就进行抽象也是合理的。
- 代码质量：在决定重构之前，评估现有代码的质量和复杂度是很重要的。如果重复的代码导致了严重的技术债务或者明显降低了代码质量，那么及早重构可能更为合适。
总的来说，Rule of Three是帮助开发者在重构过程中做出明智决策的实用原则，它鼓励在有足够证据表明抽象是有益的情况下进行重构，以提高代码的质量和可维护性。