@EventListener 方法是否应该包含在接口中？答案

【问题标题】：Should @EventListener methods be included on the interface?@EventListener 方法是否应该包含在接口中？
【发布时间】：2018-02-07 14:50:59
【问题描述】：

也许这是一个容易被删除的问题，但以防万一。

我最近在对我的服务执行 @EventListener 注释的方法时怀疑这些方法是否应该包含在服务的接口中。

我的意思是，像这样的类：

class FooServiceImpl implements FooService {
    @EventListener
    public void doSomethingWithEvent(ApplicationEvent event){
        // do something
    }
}

doSomethingWithEvent 应该包含在FooService 中吗？

我认为不应该这样做，因为该方法不应该由任何其他实例直接调用，而是由管理事件的实例直接调用。

但是，另一方面，我的服务上会有一个不包含在接口中的公共方法，并且由于某种原因，这对我来说很糟糕（也许这只是一种习惯）。

那么，该怎么办？有没有这方面的约定？

【问题讨论】：

这取决于您是否认为此服务需要对这些类型的事件作出反应。
我会为 doSomethingWithEvent 做一个自己的接口，并称之为 - 就像 - ApplicationEventAware。总而言之，我认为这主要是基于意见的主题。
Where should @Service annotation be kept? Interface or Implementation?的可能重复
@pvpkiran，并不是真正的重复。 @Service 注释与@EventListener 的含义不同。
@M.Prokhorov 有什么不同，Spring 处理方式相同。可能是内部不同。但是即使对于这个问题，这个问题的答案也很好

标签： java spring events coding-style

【解决方案1】：

我会说这是主要基于意见，因为 afaik 对于这个问题没有真正的约定。我没有标记您的问题，因为我认为这是一个很好的问题，而且我不确定它是合题还是题外话。

问自己以下问题：doSomethingWithEvent() 是我服务的一部分吗？它是合同的一部分，它的消费者（使用FooService 的类）正在使用吗？

或者将其分解：在任何情况下，使用FooService 的方法应该能够直接调用doSomethingWithEvent()？
我不这么认为。

所以，考虑到这一点，基本上：不，你不应该在你的接口中包含那个方法。针对接口进行编程意味着你向你的消费者提供接口，他们可以在不需要的情况下与他们交谈了解它的实现。这意味着一个接口也可能有（恕我直言should be）不同的实现。有些可能提供 EventListener，有些则不提供。

我个人更喜欢创建一个自己的接口 - 比如说ApplicationEventAware 并在FooServiceImpl 中实现它。您会在 Spring 中多次找到这种方法。对于这种情况，我将我的实现命名为EventAwareFooService，并避免使用*Impl 类，因为在我个人看来this is bad design。 (and some might call it an anti pattern)

已经有ApplicationListener<E extends ApplicationEvent> 那么为什么不直接实现呢？

【讨论】：

我没有使用它，因为它是进行事件监听的“旧”方式spring.io/blog/2015/02/11/…
那里没有说“旧”的方式，是吗？是的，新注释很棒，但专用界面不是您特定情况的最佳方法吗？
@Alfergon 我添加了一些参考资料并试图使我的陈述更清晰
嗨，Clijsters，如果您发现某个问题主要基于意见，请将其标记为此类（或在您的声望超过 3,000 时进行投票），而不是的回答。在 Stack Overflow，POB 问题是题外话。
如果我确定的话，我已经标记了它。我不确定这个问题更多的是关于最佳实践请求还是基于意见的问题。

【解决方案2】：

我认为对此没有任何约定。但是，我同意 doSomethingWithEvent() 不应包含在 FooService 中。看看其他人对此的看法会很有趣。

【讨论】：