この記事では主にC#における抽象クラスとインターフェースの違いについて紹介します。非常に良い基準値を持っています。エディターで見てみましょう
1. インターフェース指向プログラミングとオブジェクト指向プログラミングの関係は何ですかまず、インターフェース指向プログラミングとオブジェクト指向プログラミングは同じレベルではありません。 、それらはオブジェクト指向プログラミングよりも優れているわけではありません。 プログラミングは、より高度な独立したプログラミングの概念ですが、オブジェクト指向のイデオロギー システムに付属しており、その一部です。つまり、オブジェクト指向プログラミングにおける考え方の本質の一つです。
2. インターフェイスの本質インターフェイスは、表面的には、本体コードのないいくつかのメソッド定義のコレクションです。これは、一意の名前を持ち、クラスまたは他のインターフェイスによって実装できます。と言いました
継承)。形式的には次のようになります: interface InterfaceName
{
void Method1();
void Method2(int para1);
void Method3(string para2,string para3);
}
それでは、インターフェイスの本質は何でしょうか?つまり、インターフェースの存在意義とは何なのか。それは次の 2 つの観点から考えることができると思います:
1) インターフェースはルールのセットであり、このインターフェースを実装するクラスまたはインターフェースが持たなければならない一連のルールを規定します。それは、「あなたが…であるなら、あなたは…できるはずです」という自然の哲学を体現しています。 例えば、自然界では人は食べることができます、つまり「人間であれば食べられるはずです」。次に、コンピュータ プログラムにシミュレートされるときは、Iperson (通常、インターフェイス名は「I」で始まります) インターフェイスと Eat() というメソッドが必要です。次に、「person」を表すすべてのクラスが IPersonal インターフェイスを実装する必要があると規定します。 「人間である以上、食べなければいけない」という自然の法則をシミュレートしています。
ここからは、オブジェクト指向の考え方についてもわかると思います。オブジェクト指向の考え方の中核の 1 つは、現実世界をシミュレートし、現実世界の物事をクラスに抽象化し、プログラム全体が各クラスのインスタンスに依存して相互に通信し、相互に連携してシステム機能を完成させることです。現実世界の動作条件と非常に一致しており、オブジェクト思考の本質を指向しています。
2) インターフェースは、類似のものを特定の粒度 view で抽象的に表現したものです。ここで私が特定の粒度のビューを強調していることに注意してください。「類似のもの」の概念は相対的なものであり、粒度の異なるビューによって概念が異なるためです。 例えば、私の目から見ると、私は豚とは根本的に異なる人間であり、クラスメートと私が同じ種類であることは受け入れることができますが、私と豚が同じ種類であることは決して受け入れられません。しかし、動物学者の目から見て、ブタと私は同じ種類であるはずです。なぜなら、私たちはどちらも動物だからです。動物学者は、動物
の行動を研究するとき、「人」と「ブタ」の両方が IAnimal インターフェースを実装していると考えることができます。は私と豚を分けて扱うのではなく、「動物」というより大きな粒度から研究しますが、私と木の間には本質的な違いがあると考えるでしょう。 今、私には遺伝学者がいますが、状況はまた異なります。すべての生き物は遺伝する可能性があるため、彼の目には私は豚と何ら変わらないだけでなく、蚊、細菌、木、キノコでも豚でも、SARS ウイルスと SARS ウイルスの間に違いはありません。なぜなら、彼は、私たち全員が IDesc
endable インターフェース (注: 子孫 vi. 継承) を実装している、つまり、私たち全員が遺伝性があると考えるからです。そして、彼は私たちを別々に研究するのではなく、すべての生き物を同じ種類として研究するでしょう。彼の目には人間とウイルスの区別はなく、遺伝可能な物質と非遺伝的な物質だけが存在します。しかし、少なくとも私と石の間には違いがあります。 しかし、ある日、不幸なことが起こりました。彼の名前はレーニンでした。彼はマルクスとエンゲルスの弁証法的唯物論の傑作を読んだ後、有名な定義を下しました。いわゆる実体とは、意識によって反映される客観的な現実です。この時点では、私と、石、空気の息、慣用句、そして携帯電話の信号を送信する電磁場との間に違いはありません。なぜなら、レーニンの目には、私たちは皆、意識によって反映される客観的な現実だからです。レーニンがプログラマーだったら、こう言うでしょう。いわゆる物質とは、「IReflectabe」インターフェースと「IEsse」インターフェースの両方を実装するすべてのクラスによって生成されるインスタンスです。 (注: 反映する vs. 反映する 本質 n. 客観的な現実)
おそらく、上記の例はナンセンスだと思われるかもしれませんが、これがまさにインターフェイスが存在する理由です。オブジェクト指向の思考の中核となる概念の 1 つはポリモーフィズムと呼ばれます。ポリモーフィズムとは何ですか?平たく言えば、似たものをある粒度ビュー層で分け隔てなく一律に扱うということです。あえてこんなことをする理由はインターフェースの存在です。遺伝学者と同様に、彼はすべての生物が IDescendable インターフェイスを実装していることを理解しているため、生物である限り Descend() メソッドが必要です。これにより、各生物を個別に研究して最終的に疲れ果ててしまうのではなく、統合された研究を行うことができます。
おそらく、ここではインターフェイスの性質と機能について直感的な印象を与えることはできません。次に、次の例といくつかのデザイン パターンの分析で、インターフェイスの意味をより直観的に体験することができます。
3. インターフェース指向プログラミングの概要
それでは、インターフェース指向プログラミングとは何でしょうか?私の個人的な定義は次のとおりです: システム分析とアーキテクチャでは、レベルと依存関係を区別します。各レベルは、上位層にサービスを直接提供しません(つまり、上位層で直接インスタンス化されません)。インターフェイスのセットは、そのインターフェイス機能を上位層にのみ公開します。上位層はインターフェイスにのみ依存し、特定のクラスには依存しません。
これを行うことの利点は明らかです。まず、システムの柔軟性が向上します。下位層を変更する必要がある場合、インターフェースとインターフェース機能が変更されていない限り、上位層は変更を加える必要がありません。 WD 60G ハードドライブを Seagate 160G ハードドライブに交換するのと同じように、上位層のコードを変更せずに下位層全体を置き換えることもできます。代わりに、コンピュータの他の部分に変更を加える必要はありません。コンピュータの他の部分は特定のハード ディスクに依存せず、ハード ディスクがこのインターフェイスを実装している限り、IDE インターフェイスのみに依存するため、新しいハード ドライブを接続するだけです。交換できます。ここからは、プログラム内のインターフェースと現実のインターフェースがよく似ているので、インターフェースという言葉は本当に似ているなといつも思います!インターフェイスを使用するもう 1 つの利点は、インターフェイスが一貫していれば、ハード ドライブを構築する開発者が CPU やモニターを構築するのを待つ必要がないのと同じように、さまざまなコンポーネントまたはレベルの開発者が並行して作業を開始できることです。設計が合理的であり、並行して開発できるため、効率が向上します。
この記事の補足:
1.「インターフェース指向プログラミング」の「インターフェース」と特定のオブジェクト指向言語の「インターフェース」という2つの単語について友人がこう言っているのを見ました。 「インターフェース指向プログラミング」 「プログラミング」の「インターフェース」という言葉は、単純な
プログラミング言語の「インターフェース」という言葉よりも広い範囲を含むべきです。考えてみると、それは当然だと思います。ここに書いたことは確かに無理があります。オブジェクト指向言語における「インターフェース」とは、C#のinterfaceキーワードで定義されるインターフェースなど、特定のコード構造を指すと思います。 「インターフェイス指向プログラミング」の「インターフェイス」は、ソフトウェア アーキテクチャの観点およびより抽象的なレベルから、特定の基礎となるクラスを隠し、ポリモーフィズムを実装するために使用される構造コンポーネントを指すと言えます。この意味で、抽象クラスが定義され、ポリモーフィズムを実現することが目的であれば、この抽象クラスを「インターフェイス」と呼ぶのが妥当だと思います。しかし、ポリモーフィズムを実装するために抽象クラスを使用するのは合理的でしょうか?以下の 2 番目の記事で説明します。 要約すると、「インターフェイス」という 2 つの概念は互いに異なり、相互に関連していると思います。 「インターフェイス指向プログラミング」のインターフェイスは、ポリモーフィズムを実現し、ソフトウェアの柔軟性と保守性を向上させるために使用されるイデオロギー レベルのアーキテクチャ コンポーネントですが、特定の言語の「インターフェイス」は、このイデオロギー レベルでコードに実装される具体的なコンポーネントです。 。
2. 抽象クラスとインターフェイスについて特定のコードだけを見ると、これら 2 つの概念について曖昧になりやすく、特定の関数だけの観点から見ると、インターフェイスが冗長であるとさえ考えられます。 , 多重継承 (C#、Java) を除いて、抽象クラスはインターフェイスを完全に置き換えることができるようです。しかし、多重継承を実装するためのインターフェースは存在するのでしょうか?もちろん違います。私の意見では、抽象クラスとインターフェイスの違いは、それらを使用する動機にあります。抽象クラスを使用する目的はコードの再利用ですが、インターフェイスを使用する動機はポリモーフィズムを実現することです。したがって、インターフェイスを使用するか抽象クラスを使用するか迷っている場合は、その動機を考えてください。
Iperson インターフェイスについて疑問を抱いている友人を何人か見かけましたが、私の個人的な理解では、Iperson インターフェイスを定義する必要があるかどうかは、特定のアプリケーションによって異なると考えています。プロジェクトに Women と Man があり、両方とも person を継承し、Women と Man のほとんどのメソッドは同じですが、DoSomethingInWC() メソッドが 1 つだけ異なります (例はかなり下品です、ご容赦ください) 場合、もちろん、 AbstractPerson 抽象クラスを定義する方が合理的です。これは、他のすべてのメソッドを含めることができ、サブクラスは DoSomethingInWC() のみを定義するため、繰り返されるコードの量が大幅に削減されます。
但是,如果我们程序中的Women和Man两个类基本没有共同代码,而且有一个PersonHandle类需要实例化他们,并且不希望知道他们是男是女,而只需把他们当作人看待,并实现多态,那么定义成接口就有必要了。
总而言之,接口与抽象类的区别主要在于使用的动机,而不在于其本身。而一个东西该定义成抽象类还是接口,要根据具体环境的上下文决定。
再者,我认为接口和抽象类的另一个区别在于,抽象类和它的子类之间应该是一般和特殊的关系,而接口仅仅是它的子类应该实现的一组规则。(当然,有时也可能存在一般与特殊的关系,但我们使用接口的目的不在这里)如,交通工具定义成抽象类,汽车、飞机、轮船定义成子类,是可以接受的,因为汽车、飞机、轮船都是一种特殊的交通工具。再譬如Icomparable接口,它只是说,实现这个接口的类必须要可以进行比较,这是一条规则。如果Car这个类实现了Icomparable,只是说,我们的Car中有一个方法可以对两个Car的实例进行比较,可能是比哪辆车更贵,也可能比哪辆车更大,这都无所谓,但我们不能说“汽车是一种特殊的可以比较”,这在文法上都不通。
C#.NET里面抽象类和接口有什么区别?
接口和抽象类的概念不一样。接口是对动作的抽象,抽象类是对根源的抽象。
抽象类表示的是,这个对象是什么。接口表示的是,这个对象能做什么。比如,男人,女人,这两个类(如果是类的话……),他们的抽象类是人。说明,他们都是人。
人可以吃东西,狗也可以吃东西,你可以把“吃东西”定义成一个接口,然后让这些类去实现它.
所以,在高级语言上,一个类只能继承一个类(抽象类)(正如人不可能同时是生物和非生物),但是可以实现多个接口(吃饭接口、走路接口)。
下面接着再说说两者在应用上的区别:
接口更多的是在系统架构设计方法发挥作用,主要用于定义模块之间的通信契约。
而抽象类在代码实现方面发挥作用,可以实现代码的重用
模板方法设计模式是抽象类的一个典型应用
最佳答案:
1抽象类
(1) 抽象方法只作声明,而不包含实现,可以看成是没有实现体的虚方法
(2) 抽象类不能被实例化
(3) 抽象类可以但不是必须有抽象属性和抽象方法,但是一旦有了抽象方法,就一定要把这个类声明为抽象类
(4) 具体派生类必须覆盖基类的抽象方法
(5) 抽象派生类可以覆盖基类的抽象方法,也可以不覆盖。如果不覆盖,则其具体派生类必须覆盖它们。如:
using System; public abstract class A //抽象类A { private int num=0; public int Num //抽象类包含属性 { get { return num; } set { num = value; } } public virtual int getNum() //抽象类包含虚方法 { return num; } public void setNum(int n) // //抽象类包含普通方法 { this.num = n; } public abstract void E(); //类A中的抽象方法E } public abstract class B : A //由于类B继承了类A中的抽象方法E,所以类B也变成了抽象类 { } public class C : B { public override void E() //重写从类A继承的抽象方法。如果类B自己还定义了抽象方法,也必须重写 { //throw new Exception("The method or operation is not implemented."); } } public class Test { static void Main() { C c = new C(); c.E(); } }
二、接 口
(1) 接口不能被实例化
(2) 接口只能包含方法声明
(3) 接口的成员包括方法、属性、索引器、事件
(4) 接口中不能包含常量、字段(域)、构造函数、析构函数、静态成员。如:
public delegate void EventHandler(object sender, Event e); public interface ITest { //int x = 0; int A { get; set; } void Test(); event EventHandler Event; int this[int index] { get; set; } }
(5) 接口中的所有成员默认为public,因此接口中不能有private修饰符
(6) 派生类必须实现接口的所有成员
(7) 一个类可以直接实现多个接口,接口之间用逗号隔开
(8) 一个接口可以有多个父接口,实现该接口的类必须实现所有父接口中的所有成员
三、抽象类和接口
相同点:
(1) 都可以被继承
(2) 都不能被实例化
(3) 都可以包含方法声明
(4) 派生类必须实现未实现的方法
区 别:
(1) 抽象基类可以定义字段、属性、方法实现。接口只能定义属性、索引器、事件、和方法声明,不能包含字段。
(2) 抽象类是一个不完整的类,需要进一步细化,而接口是一个行为规范。微软的自定义接口总是后带able字段,证明其是表述一类“我能做。。。”
(3) 接口可以被多重实现,抽象类只能被单一继承
(4) 抽象类更多的是定义在一系列紧密相关的类间,而接口大多数是关系疏松但都实现某一功能的类中
(5) 抽象クラスは、一連の関連するオブジェクトから抽象化された概念であるため、物事の内部的な共通性を反映し、インターフェースは、外部の呼び出しを満たすために定義された機能上の合意であるため、物事の外部の特性を反映します
(6)インターフェイスには基本的に継承の特定の特性はありません。呼び出し可能なメソッドのみを保証します。
(7) インターフェイスはコールバックをサポートするために使用できますが、継承にはこの機能がありません。
(8)具象メソッドはデフォルトで仮想ですが、インターフェイスを実装するクラスのインターフェイス メソッドはデフォルトで非仮想として宣言することもできます
(9) 抽象クラスがインターフェイスを実装する場合、メソッドをインターフェースへの抽象メソッドを抽象クラスに実装する必要はありませんが、インターフェース内のメソッドは抽象クラスのサブクラスに実装されます
以上がC#の抽象クラスとインターフェイスの違いを詳しく解説の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。