15

インターフェイスは 100% 抽象クラスであるため、インターフェイスを使用して効率的なプログラミングを行うことができます。抽象クラスがインターフェースよりも優れている状況はありますか?

4

5 に答える 5

21

抽象クラスは、具体的なクラスを作成するつもりであるが、すべてのサブクラスに共通の状態があること、または一部の操作に対して可能な共通の実装があることを確認したい場合に使用されます。

インターフェイスにどちらも含めることはできません。

于 2008-11-27T04:47:23.483 に答える
9

はい、抽象クラスとインターフェースの両方のための場所があります。

具体的な例を見てみましょう。アブストラクトからCheckingAccountとを作成する方法を調べ、インターフェイスを使用して2つのタイプのアカウントを区別する方法を確認します。SavingsAccountAbstractBankAccount

まず、抽象クラスを次に示しAbstractBankAccountます。

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

アカウントの残高はbalance2つのメソッドとしてあり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では、2つの抽象クラスを実装しました。ここではあまり興味深いものはありません。

では、どのように実装できます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インターフェースは、異なるクラスに共通の機能を追加していると見なすことができます。当座預金口座に利息が発生しない場合に、当座預金口座の利息を処理する機能があることは意味がありませんでした。

したがって、抽象クラスとインターフェースの両方が1つの状況で共存し、連携する場所が実際にあります。

于 2008-11-27T06:20:55.697 に答える
5

抽象クラスv/sインターフェースは、Javaを初めて使用し、さらに深く掘り下げたいと考えている人にとって、多くの好奇心/興味/混乱を生み出すトピックの1つです。

この記事では、このトピックに関する詳細な説明を提供します。

于 2008-11-27T05:31:35.733 に答える
2

インターフェイスよりも実装不要の抽象クラスを好む理由はいくつかあります。

  • 特定の不可能なキャストとinstanceof操作は、コンパイル時にキャッチされる可能性があります。
  • 後のバージョンで具体的なメソッドを追加するオプションがあります。
  • 何年も前には、パフォーマンスに大きなメリットがありました。
  • 非常にあいまいなセキュリティの観点から、既存のクラスと抽象クラスのサブクラスを作成してメソッドを実装するための既存のクラスを取得することはできません。

しかし一方で、interfaceJavaキーワードはよりクリーンなソースを可能にします。

于 2008-11-27T14:05:23.590 に答える
0

一般に、インターフェイスはコードで使用するパブリック API を記述しますが、抽象基本クラスは実装の詳細として保持するのが最適であり、共通のコードまたは状態を保持して、実装クラスの重複を減らすことができます。

API でインターフェイスを使用すると、外部リソースに依存しないテスト クラスや、明示的な種類のテスト クラスを使用できるため、(あなたを含む) 人々がクラスに対してテスト コードを記述しやすくなります。悪いが、実際の行動をシミュレートするのは難しい.

したがって、JavaはListインターフェースと、インターフェースを「実装するために必要な労力を最小限に抑える」ためのAbstractList抽象基本クラスを提供します...

于 2008-11-27T11:37:11.797 に答える