需要抽象类和接口吗？

StackOverflow https://stackoverflow.com/questions/322945

  •  11-07-2019
  •  | 
  •  

题

接口是100%的抽象类，因此我们可以使用接口进行高效的编程。有没有抽象类比接口更好的情况？

有帮助吗？

解决方案

当你打算创建一个具体的类抽象类的使用， 但要确保有一定的常见状态在所有子类 或可能的常见的实施作为一些操作。

接口不能包含任

其他提示

是，存在对既抽象类和接口的地方。

让我们用一个具体的例子。我们将研究如何使CheckingAccount和SavingsAccount从抽象AbstractBankAccount，看看我们如何能够使用一个接口区分这两种类型的帐户。

要开始，这里是一个抽象类AbstractBankAccount：

abstract class AbstractBankAccount
{
    int balance;
    public abstract void deposit(int amount);
    public abstract void withdraw(int amount);
}

我们获得了帐户余额balance和两个方法deposit和withdraw必须由子类来实现。

我们可以看到，一个的抽象类声明的银行账户应当如何定义的结构即可。如@Uri在他的响应提到，有一个状态此抽象类，这是balance字段。这是不可能用一个接口。

现在，让我们的子类AbstractBankAccount做出CheckingAccount 

class CheckingAccount extends AbstractBankAccount
{
    public void deposit(int amount)
    {
        balance += amount;
    }

    public void withdraw(int amount)
    {
        balance -= amount;
    }
}

在本小类CheckingAccount，我们实施了两个抽象类 - 没有什么太有趣了这里

现在，我们怎么能实现SavingsAccount？这是一个从CheckingAccount，它会获得利益不同。利息可以增加使用deposit方法，但话又说回来，它并不像如果客户沉积兴趣他/她。因此，如果我们在将钱存入一个账户的另一种手段，专门为兴趣，比方说，一个accrueInterest方法可能更清晰。

我们可以直接实现在SavingsAccount的方法，但是我们可以具有能够在未来计息更多的银行帐户类型，所以我们可能要做出具有InterestBearing方法的accrueInterest接口：

interface InterestBearing
{
    public void accrueInterest(int amount);
}

所以，我们现在可以做出SavingsAccount类可以通过实现InterestBearing接口获得利益：

class SavingsAccount extends AbstractBankAccount implements InterestBearing
{
    public void deposit(int amount)
    {
        balance += amount;
    }

    public void withdraw(int amount)
    {
        balance -= amount;
    }

    public void accrueInterest(int amount)
    {
        balance += amount;
    }
}

现在，如果我们想使其他类型的帐户，说PremiumSavingsAccount，我们可以使AbstractBankAccount的子类，并实现InterestBearing接口再拍息账户。

在InterestBearing接口可以被看作是的添加的共同特征以不同的类。这本来并没有意义，有一个功能来应对支票账户利息时不会获得任何利益。

因此，确实有两个抽象类和接口的地方共存，在一种情况下一起工作。

抽象类V / s接口是任何人都对Java产生很大的好奇心/利息/困惑，并希望深入挖掘一个话题。

此文章提供关于这一主题的详细说明。

您可能更喜欢无实现的抽象类而不是接口，原因有几个：

  • 某些不可能的强制转换和instanceof操作可以在编译时被捕获。
  • 您确实可以选择在更高版本中添加具体方法。
  • 许多年前，曾经有过显着的性能优势。
  • 从高度模糊的安全角度来看，您无法通过创建预先存在的类和抽象类的子类来获得预先存在的类来实现方法。

但另一方面，interface Java 关键字允许更清晰的源代码。

在一般情况下，接口描述代码应该使用公共API，而抽象基类，最好保持为一个实现细节，其中共同代码或状态可以被保持，以减少在任何实现类重复。

通过您的API使用的接口，它成为人们（包括你）编写针对你的类测试代码，因为你可以使用，例如，不依赖于任何外部资源测试类，或表现出更容易明确各种恶劣，但是，难以模拟功能于现实生活中的行为。

所以Java提供List接口，并且AbstractList的抽象基类为“最小化来实现所需的努力”接口...

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top