介绍
在面向对象编程 (oop) 中，开发人员努力追求干净、模块化的代码，并遵守单一职责和封装等原则。然而，有一种反复出现的反模式可以将代码库变成维护噩梦：上帝对象。
god object 是一个承担了太多职责的对象，成为各种不相关操作的中心点。虽然最初看起来很方便，但随着时间的推移，它会导致紧密耦合且难以维护的代码。在本文中，我们将探讨什么是 god objects、它们为何存在问题以及如何避免它们。
什么是神物？
上帝对象（或上帝类）是在系统中承担过多责任的类。它违反了关键的软件设计原则，例如单一职责原则 (srp)，该原则规定一个类只能有一个更改的理由。
上帝对象往往会不受控制地增长，封装逻辑上应属于多个较小的专门类的数据和方法。
神物的特征：
- 处理不密切相关的多种职责。
- 对系统中的其他对象了解太多。
- 包含过多的逻辑或数据操作。
- 充当瓶颈，系统中的每个操作都依赖于它。
为什么上帝对象有问题？
违反 oop 原则：
通过将不相关的职责捆绑到一个类中来打破 srp。
导致缺乏内聚力和紧密耦合的代码。
维护困难：
对上帝对象的更改可能会在整个系统中产生意想不到的连锁反应。
由于其相互关联性，测试和调试变得复杂。
可扩展性问题：
god object 的整体性阻碍了代码的可扩展性。
添加新功能需要修改臃肿的类，增加技术债务。
可读性降低：
由于 god object 的职责庞大，开发人员很难理解它的目的。
上帝对象的例子
javascript 中的 god 对象示例：
class godobject {
constructor() {
this.users = [];
this.orders = [];
this.inventory = [];
}
// user-related methods
adduser(user) {
this.users.push(user);
}
finduser(userid) {
return this.users.find(user => user.id === userid);
}
// order-related methods
addorder(order) {
this.orders.push(order);
}
getorder(orderid) {
return this.orders.find(order => order.id === orderid);
}
// inventory-related methods
addinventoryitem(item) {
this.inventory.push(item);
}
getinventoryitem(itemid) {
return this.inventory.find(item => item.id === itemid);
}
}
在此示例中，godobject 类负责用户管理、订单处理和库存跟踪——理想情况下应该将三个不同的关注点分开。
重构上帝对象
为了解决这个问题，请将上帝对象划分为更小的、专门的类，每个类负责一个域。
重构示例：
class UserManager {
constructor() {
this.users = [];
}
addUser(user) {
this.users.push(user);
}
findUser(userId) {
return this.users.find(user => user.id === userId);
}
}
class OrderManager {
constructor() {
this.orders = [];
}
addOrder(order) {
this.orders.push(order);
}
getOrder(orderId) {
return this.orders.find(order => order.id === orderId);
}
}
class InventoryManager {
constructor() {
this.inventory = [];
}
addInventoryItem(item) {
this.inventory.push(item);
}
getInventoryItem(itemId) {
return this.inventory.find(item => item.id === itemId);
}
}
现在每个类都有一个职责，使系统模块化，更易于维护且可扩展。
如何避免上帝的对象
遵守单一责任原则：
确保每个班级都有明确且集中的职责。
拥抱组合而非继承：
使用组合将更小的、专门的类聚合成更高级别的构造。
使用领域驱动设计（ddd）进行设计：
识别并分离应用程序中的域，并创建与这些边界一致的类。
定期重构：
不断评估大型类并将其重构为更小的、有凝聚力的组件。
使用设计模式：
factory、mediator 和 observer 等模式可以通过分配职责来帮助防止类臃肿。
结论
上帝对象在最初的开发过程中可能看起来像是一条捷径，但其长期后果超过了任何短期利益。通过遵循可靠的设计原则、利用设计模式并定期重构代码，您可以避免 god objects 的陷阱并构建健壮、可维护的系统。
今天就认识到你的代码库中存在上帝对象的迹象，并采取积极主动的措施来解决它。未来的你和你的团队都会感谢你！
