3

私は再利用可能なライブラリを開発していて、抽象クラスを作成しているので、クライアントはこれらから拡張できます。

質問：通常のクラスではなく、ここで抽象クラスを使用する必要がある理由はありますか？

注-ライブラリに実際のデフォルトメソッドを含めたいので、インターフェイスを使用しないことをすでに決定しているので、それを使用するクライアントはコードを記述する必要がありません。

編集：だから私は私が考えることができない利点のために釣りをしています。たとえば、ライブラリをアップグレードするときに抽象クラスを使用すると、クライアントコードへの影響が少なくなります。この場合はわかりません。

4

4 に答える 4

3

エンドユーザーにクラスからの継承を強制したい場合を除いて、 abstractを使用する理由はありません。

クラスを継承可能で簡単に拡張できるようにする場合は、メソッドで仮想を使用し、使用可能な保護されたコンストラクターがあることを確認してください。

于 2010-05-11T02:23:09.790 に答える
3

抽象クラスの動機は、クライアントにクラスのオーバーライドを要求することです。クラスを抽象化するかどうかの決定は、主に、抽象化にクラスのユーザーだけが提供できる基本的な動作が欠けているかどうかに依存します。

ある種のテンプレートメソッドを使用する場合は、通常、クラスを抽象化する必要があると言うことができます。この場合、「この動作の穴を塞ぐ」と、クラスのロジックが完成します。ユーザーが提供するロジックがなくてもクラスが役立つ場合は、クラスを抽象化する必要はおそらくありません。

たとえば、フレームワークは通常、オブジェクトの状態の検証、印刷、表示などの点でユーザーに代わって決定を下すことができず、クライアントによる具体的な実装に従う必要があります。

于 2010-05-11T02:31:46.030 に答える
2

抽象クラスと非抽象クラスの違いは、前者をインスタンス化することはできず、オーバーライドする必要があることです。基本クラスのインスタンスがそれ自体で意味をなすかどうかを判断するのは、実際にはあなた次第です。

2つのケースをお見せしましょう。1つは抽象クラスが理にかなっている場合と、そうでない場合です。

public abstract class Animal {
  public string Name {get;set;}
}

public class Dog : Animal {
  public Bark(){}
}

public class Cat : Animal {
  public Meaow(){}
}

このシナリオでは、プロパティAnimalの実装を提供する共通ベースがありNameます。動物だけである動物は世界に存在しないので、動物を単独でインスタンス化することは意味がありません。それらは枯れた犬や猫、または他の何かです。

これは、非抽象ベースを持つことが理にかなっている場合です。

class Path {
  public Path(IList<Point> points) {
    this.Points = new ReadOnlyCollection<Point>(points);
  }
  public ReadOnlyCollection<Point> Points {get;}
}

class RectanglePath : Path{
  public SquarePath (Point origin, int height, int width) : 
   base(new List<Point>{origin, new Point(origin.X + width, point.Y}, ....){

  }
}

ここでは、サブクラス化されていないパスが理にかなっています。任意の形状を作成できますが、より具体的な形状にはサブラスを使用する方が便利な場合があります。

于 2010-05-11T02:21:14.277 に答える
1

仮想メソッドと抽象クラスの違いについて少し混乱しているようです。それ自体では意味がないと判断しない限り、クラスを抽象としてマークする必要はありません。これは、複数のクラス間で動作を共有している可能性がある領域で役立ちます。

通常のクラスと仮想のメソッドが必要なように思えます。

于 2010-05-11T02:24:09.180 に答える