它似乎是标准所以我到目前为止一直在使用它，但现在我正在从头开始构建一个新类而不是修改旧类，并且我觉得我应该理解为什么我应该遵循项目约定。
几乎每个类都有一个名为classnameable的接口。在代码database.class中，即使只出现一次，但在我想要使用该类的地方，我会看到databaseable.class。
根据我的理解，界面是一个从未实现但仍然保留标准的类。那么为什么接口被用作真正的类呢？
答案 0 :(得分：9)
据我所知，界面是一个永远不会的类 已经实施但保留了标准。那么为什么呢？ 接口被用作真正的类。
这有点困惑。接口定义API，以便来自不同作者，模块或项目的代码片段可以进行交互。例如，java.util.Collections.sort()可以对实现List接口的任何内容进行排序，并包含实现Comparable接口的对象 - 即使在编写排序代码时可能还没有实现类！
现在你的项目中的情况似乎反映了一个不幸的相当常见的反模式：拥有所有的接口，主要是单个实现类，甚至是内部类。
以前，测试驱动开发（TDD）的支持者强烈推动这一点，他们认为能够独立测试每个类，并将所有依赖项替换为模拟对象是至关重要的。较旧的模拟框架只能模拟接口，因此为了能够隔离地测试每个类，所有类间依赖都必须通过接口。
幸运的是，较新的模拟框架可以模拟具体的类，并且不要求您使用不必要的接口污染您的项目。有些人可能仍会争辩说无论如何都应该“减少耦合”，但是IMO他们只是合理化他们不改变他们的做法的愿望。
当然，如果你不做原教旨主义TDD，那么就没有充分的理由为所有东西建立一个界面 - 但是有很好的理由为某些东西设置接口。
答案 1 :(得分：2)
如果你的项目中几乎每个类都有一个界面，即使没有理由，这也不是一件好事，而且在这个时代，没有什么好理由。例如，当某些外部测试工具包需要它时，这可能是遗留下来的遗产 - 但这些日子并不是必需的。
当然可能有人听说松耦合是一件好事，你应该总是耦合到接口而不是具体的类，并将这个想法推向极致。
另一方面，优良作法是为某些类定义接口，即使只有其中一个类（此刻）。当我写一个类时，我试着按照是否另一个类（可能是有用的）实现可能存在，如果是这样，我将把接口放入。如果它没有使用它没有问题，但如果它是它节省时间和麻烦和稍后重构。
答案 2 :(得分：1)
如果你想为你的接口创建一个类，那么常见的方法是创建一个AbstractFoo类来与Foo接口一起使用。您可以提供所需方法的简单实现，允许派生类根据需要覆盖它们。有关此类的示例，请参阅AbstractCollection。
优点是你不必实现所有小东西，它已经为你完成了。缺点是您不能从任何其他类继承。你支付了钱，然后你可以选择。
答案 3 :(得分：1)
糟糕设计的好指示是指ISomething或SomethingImpl。接口名称应说明如何使用它（即List），类名应说明它是如何工作的（即ArrayList）。
如果您需要前缀或后缀，因为名称相同，这意味着只有一种方法可以实现它，然后可能不需要分离。 （如果您认为将来会有更复杂的实施，请将您的课程命名为DefaultSomething或SimpleSomething）