oop - 构造函数中的业务逻辑是一个好主意吗？

Question

我目前正在重建工作中的专用票务系统(主要用于为遥感硬件有故障的人提供支持...)。无论如何，我想知道在对象的构造函数中进行大量工作流类型 Activity 是否是一个好主意。

例如，当前有:

$ticket = new SupportTicket(
    $customer,
    $title,
    $start_ticket_now,
    $mail_customer
);

创建对象后，它将立即放入数据库中，然后向客户发送确认电子邮件，还可能向附近的技术人员发送文本消息，等等。

构造函数是否应该解雇所有这些工作，或者更像以下内容？

$ticket = new SupportTicket($customer, $title);
$customer->confirmTicketMailed($ticket);
$helpdesk->alertNewTicket($ticket);

如果有帮助，则所有对象均基于ActiveRecord样式。

我想这可能只是个见解，但您认为最好的做法是什么？

Answer 1

如果构造函数完成了所有工作，那么构造函数就会知道许多其他域对象。这产生了依赖性问题。 ticket应该真正了解Customer和HelpDesk吗？添加新功能后，是否有可能将新的域对象添加到工作流中，这是否意味着我们可怜的ticket将不得不了解域对象的数量不断增加的情况？

像这样的依赖蜘蛛网的问题是，对任何一个域对象进行源代码更改都会对我们不良的ticket产生影响。 ticket对系统有足够的了解，因此无论发生什么情况，都会涉及ticket。您会发现讨厌的if语句聚集在该构造函数中，检查配置数据库， session 状态以及许多其他内容。 ticket将成长为神类。

我不喜欢构造函数执行操作的另一个原因是，它使周围的对象很难测试。我喜欢写很多模拟对象。当我针对customer编写测试时，我希望通过一个模拟的ticket。如果ticket的构造函数控制工作流程以及customer和其他域对象之间的冲突，那么我不太可能将其模拟出来以测试customer。

我建议您阅读The SOLID Principles，这是我几年前写的一篇关于管理面向对象设计中的依赖关系的论文。