将业务逻辑放在侦听器/执行器类中是一种不好的做法吗？

Question

当使用诸如消息队列（RabbitMQ等）或调度框架（Quartz等）之类的框架时，需要实现一些框架的接口（Job接口或{{ 1}}接口）。避免将任何业务逻辑放在实现中，并立即委托给其他类，这是一种常见做法。例如：

MessageListener

从OO的角度来看，由于单一责任原则，这是有道理的。但除此之外，它只会导致阶级膨胀，以及过于分层的代码。

授权是否有任何实际好处？

Answer 1

关于原则的好处是它们有很多。

在您的情况下，我会选择简单直接的实施方式。 现在没有必要提取业务逻辑;我们总是可以在以后需要的时候这样做。

Answer 2

委派的一个实际好处是，如果您需要切换到不同的框架/队列/接口/任何内容，或者除了当前需要添加另一个之外，您可以重用业务逻辑（例如，您和＃39;将您的业务方法重新公开为Web服务，但又希望添加REST API。

Answer 3

在许多情况下，你应该在回调中花费很少的时间。例如，在Android中，在UI回调中花费太多时间（在UI线程中运行）将阻止您的应用程序。

来自Android documentation：

  

具体来说，如果UI线程中发生了所有事情，执行网络访问或数据库查询等长时间操作将阻止整个UI。线程被阻止时，不会调度任何事件，包括绘制事件。从用户的角度来看，应用程序似乎挂起了。更糟糕的是，如果UI线程被阻止超过几秒钟（当前大约5秒），则向用户呈现臭名昭着的应用程序没有响应＆＃34; （ANR）对话框。