为什么将接口声明为抽象？
将接口声明为抽象有什么意义？接口方法也是如此。有什么意义吗？
例如。
public abstract interface Presenter {
public abstract void go(final HasWidgets container);
}
问题答案：
您在哪里遇到过已发布的代码块，任何旧的Java代码库？
这就是
JLS不得不说：
9.1.1.1抽象接口：
每个接口都是隐式抽象的。该修饰符已过时，不应在新程序中使用。
9.4抽象方法声明：
为了与Java平台的较早版本兼容，出于风格考虑，允许但不鼓励为接口中声明的方法冗余地指定abstract修饰符。
-
问题内容： 今天，我使用了Eclipse的“拉接口”重构功能来创建基于现有类的接口。该对话框提供了将新界面的所有新方法创建为“抽象”方法的功能。 那会有什么好处？ 我认为，允许您将接口方法声明为抽象的事实是该语言的多余且无害的功能，因此不建议特别提倡。 为什么Eclipse支持这种样式，或者为什么有人自愿选择支持这种样式？ 澄清：我不是在问为什么接口方法是抽象的，这是显而易见的。我想问为什么人们会
-
问题内容： 我注意到有些人喜欢将对象声明为它实现的接口之一， 即使在变量的范围内，也不必将其视为接口 ，例如，没有期望接口的外部API。 例如： 或者你可以做 并避免完全导入。 与类本身（第二个）相反，通过接口（上面的第一个）声明它有什么好处？ 谢谢 问题答案： 如果以后不使用该变量，则没有优点/缺点。使用接口而不是对象的原因是为了提供更大的灵活性，但是，如果不使用该变量，则与性能方面没有什么区别
-
问题内容： 为什么即使该类中没有抽象方法，也将类声明为抽象？ 问题答案： 这是因为它遵循模板方法设计模式。这些方法具有返回HTTP 405 未实现方法 错误的所有默认行为。如果所有这些方法都是抽象的，那么即使您的业务需求根本不需要它们，也将不得不覆盖所有这些方法。这只会导致样板代码和不确定/不直观的行为。
-
问题内容： 有时我们有几个类，这些类的某些方法具有相同的签名，但是与声明的Java接口不对应。例如，和（在中的其他几个 ）中都有一个方法 现在，假设我希望对具有该方法的对象进行一些操作。然后，我想有一个接口（或者自己定义），例如 这样我可以写： 但是，可悲的是，我不能： 此演员表将是非法的。编译器 知道 这 是不是 一个，因为类没有宣布实现该接口...... 然而“实际上”实现它 。 有时这会带来
-
问题内容： 一般情况下，我无法优雅地获取图像像素作为数组。 现在，功能getPixels如下所示： 但是我认为这很丑。Golang知道图像的类型，我希望这样： 我也不能坚持。也许有一种方法可以从接口获取类型？ 问题答案： 通过使用如下所示的类型开关，可以简化大型结构： 您仍然必须列出所有可能的类型，但这更好。 由于所有图像实现都是具有名为的字段的结构指针，因此您可以使用反射来获取该字段。此实现将处
-
问题内容： 在开始阅读之前：这个问题不是关于理解monad的问题，而是关于确定Java类型系统的局限性的，这会限制接口的声明。 在我的努力去理解单子我读这个由埃里克利珀SO- 答案上询问单子简单的解释问题。在那里，他还列出了可以在monad上执行的操作： 有一种方法可以将未放大类型的值转换为放大类型的值。 有一种方法可以将未放大类型的操作转换为遵循前面提到的功能组成规则的放大类型的操作 通常，有一