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

我目前正在重建一个专门的票务系统(主要用于支持有遥感硬件故障的人......).无论如何,我想知道在对象的构造函数中做很多工作流类型活动是个好主意.

例如,目前有:

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

一旦创建了对象,它就会将一行放入数据库,然后向客户发送确认电子邮件,可能会向最近的技术人员发送短信等.

构造函数应该解雇所有工作,还是更像下面的东西？

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

如果有帮助,对象都基于ActiveRecord样式.

我想这可能是一个意见问题,但您认为最好的做法是什么？

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

像这样依赖蜘蛛网的问题是源代码改变到任何一个域对象都会对我们的穷人产生影响ticket.该ticket会有这么多,不管发生什么情况,系统的知识ticket将参与其中.您将if在该构造函数中收集讨厌的语句,检查配置数据库,会话状态以及许多其他内容.该ticket会成长成为一个神级.

我不喜欢做事情的构造函数的另一个原因是它使周围的对象很难测试.我喜欢写很多模拟对象.当我写一个测试反对customer我想通过它嘲笑ticket.如果ticket控制工作流的构造函数,customer以及其他域对象之间的舞蹈,那么我不太可能将其模拟出来进行测试customer.

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