我曾经从一本关于方法引用的书中读到以下代码。
File[] hiddenFiles = new File(".").listFiles(File::isHidden)
当我从 File API 查找该listFiles方法时，我看到它只有以下方法：
listFiles(FileFilter filter)
listFiles(FilenameFilter filter)
我已经尝试过代码并且它有效。但是，虽然 API 声明它接受FileFilter或FilenameFilter，但为什么代码可以工作？
我对 File::isHidden 的理解是它等价于以下 lambdas：
(File file) -> file.isHidden()
但在 FileFilter 中，需要指定的方法如下。
boolean accept(File pathname)
那么不应该在那里定义一个名为 accept 的方法，例如：
File[] hiddenFiles = new File(".").listFiles(new FileFilter() {
public boolean accept(File file) {
return file.isHidden();
}
});
或者编译器可以以某种方式自动检测模式并将代码视为 FileFilter，尽管未定义方法“accept”并且未创建 FileFilter 对象？
在事件驱动的微服务系统中，微服务也是 Restful API 是通常还是最佳实践？
在事件驱动的微服务中，通常被描述为引发一些事件，以及一些其他微服务响应这些事件并执行一些操作。在这种情况下，似乎没有 Restful API 中的“资源”概念。如果一个系统是使用restful API构建的，那么这个系统可以称为微服务系统吗？
在事件驱动的微服务背景下，restful 的概念还适用吗？当我开始更多地了解事件驱动的微观时，我发现自己对这两者有点混淆，并且不确定我是否正确理解了这个概念。
我了解到自动装配bean实际上不是一个好习惯。春季文档中也提到了这一点。我知道有两种类型的bean配置。一种是通过XML配置，另一种是通过Java配置类。如果我们想使用代码进行bean配置而不使用@autowired，我们该怎么做？似乎如果使用代码，我们仍然需要@autowired才能注入bean？
例如在下面，如果我们不想使用@Autowired，我们该怎么做？最佳实践应该是什么？
@Service
public class ClassA {
private ClassB classB;
@Autowired
public ClassA(ClassB classB) {
this.classB = classB;
}
}