Oop 面向对象，类/对象过度杀戮

什么是一个很好的衡量标准，可以用来判断一个类的设计是否糟糕，甚至是否有必要。换句话说，什么时候写一门课，什么时候不写。

很多人会说“坚实的原则”是一个很好的课堂设计指南

有很多关于坚实原则的文章/播客，请快速搜索。这是一个好的开始：

---

如果类设计不当，SOLID可能会有所帮助，但它无助于回答“面向对象编程是解决此问题的最佳方法吗？”

在面向对象编程开始流行之前，人们在数学和科学编程方面做了很多很好的工作。如果您的问题属于这些类别，那么面向对象编程可能不适合您

对象是状态和行为的结合体；他们倾向于一对一地映射到问题域对象。如果你的问题不是这样，也许面向对象编程不适合你

如果你不熟悉面向对象的语言，也许面向对象编程不适合你

---

如果您的组织不知道也不能支持面向对象的解决方案，那么面向对象编程可能不适合您。

在坚实的原则基础上，看看代码的味道。在Martin Fowler的《重构》一书中首先提到了它们（IIRC），这本书读得很好

代码气味通常适用于OO，在某种程度上也适用于程序开发，包括“鸟枪手术”，需要在整个代码库中进行编辑以更改一件小事，或“切换案例气味”，其中巨大的切换案例控制应用程序的流程

---

重构（书籍）最好的一点是，它推荐了修复代码气味的方法，并对它们采取了务实的态度——它们就像真实的气味一样——你可以接受其中一些，但不能接受其他气味。

与其列出一堆“不要这样做”的规则来识别设计糟糕的类，列出管理好的类设计的几个规则更容易，也更有效：

• 类是相关状态和行为的集合
• 行为应仅使用状态和方法参数
• 如果将状态视为一个关系（即关系数据库表中的列），则对象ID（指针）是主键（合成键），状态包含非键属性。对象是否为第三范式？如果没有，请将其拆分为两个或多个对象
• 对象的生命周期是否已完成？换句话说，您是否有足够的方法将对象从创建到使用，最后到销毁/处置？如果没有，缺少哪些方法（或状态/转换）
• 是否至少有一个方法使用了所有状态？如果没有，它是否提供对对象用户有用的描述性信息？如果这两个问题的答案都是否定的，那么就摆脱无关状态

---

如果您试图解决的问题不需要状态，您就不需要对象。

建议是可靠的，但我不喜欢“代码气味”这个术语；让我想到一个垃圾箱；-）我更喜欢“不适症状”或“技术债务证据”这两个词。史蒂文，你赢得了科技同义词表奖，因为它是术语的替代品。非常感谢！