C#의 추상 클래스와 인터페이스 간의 차이점에 대한 자세한 설명

이 글에서는 C#의 추상 클래스와 인터페이스의 차이점을 주로 소개합니다. 매우 좋은 참조 값을 가지고 있습니다. 아래 에디터로 살펴보겠습니다

1. 인터페이스 지향 프로그래밍과 객체 지향 프로그래밍

의 관계는 무엇입니까? 모두, 인터페이스 지향 프로그래밍 객체 지향 프로그래밍과 같은 수준은 아니지만 객체 지향 프로그래밍보다 더 발전된 독립적인 프로그래밍 아이디어는 아니지만 객체 지향 이데올로기 시스템과 관련되어 있습니다. 즉, 객체지향 프로그래밍 시스템에서 아이디어의 본질 중 하나이다.

2. 인터페이스의 본질

표면적으로 인터페이스는 본문 코드가 없는 여러 메서드 정의의 모음입니다. 클래스나 다른 인터페이스로 구현됩니다(또는 가 을 상속한다고도 말할 수 있음). 형식은 다음과 같습니다.

interface InterfaceName
{
 void Method1();
 void Method2(int para1);
 void Method3(string para2,string para3);
}

그럼 인터페이스의 본질은 무엇일까요? 즉, 인터페이스의 존재 의미는 무엇인가? 다음 두 가지 관점에서 생각해 볼 수 있을 것 같습니다.

1) 인터페이스란 이를 구현하는 클래스나 인터페이스를 규정하는 규칙의 집합입니다. 인터페이스에는 일련의 규칙이 있어야 합니다. 이는 "당신이...있다면...당신은...할 수 있어야만 합니다"라는 자연의 철학을 구현합니다.

예를 들어 자연에서는 사람이 먹을 수 있다. 즉, “사람이라면 먹을 수 있어야 한다”는 것이다. 그런 다음 컴퓨터 프로그램으로 시뮬레이션할 때 IPerson(일반적으로 인터페이스 이름은 "I"로 시작) 인터페이스와 Eat()라는 메서드가 있어야 합니다. 그런 다음 "사람"을 나타내는 모든 클래스가 IPerson 인터페이스를 구현해야 한다고 규정합니다. "인간이라면 먹을 수 있어야 한다"는 자연의 법칙을 시뮬레이션한 것입니다.

여기에서도 객체지향적 사고가 보이는 것 같아요. 객체지향 사고의 핵심 중 하나는 현실 세계와 현실 세계의 추상적인 것들을 클래스로 시뮬레이션하는 것입니다. 전체 프로그램은 각 클래스의 인스턴스에 의존하여 서로 통신하고 협력하여 시스템 기능을 완성합니다. 현실 세계의 작동 조건과 매우 일치하며 객체 사고의 본질을 지향합니다.

2) 인터페이스는 특정 세분성 뷰에서 유사한 항목을 추상적으로 표현한 것입니다. 여기서는 "유사한 것"이라는 개념이 상대적이고 세부적인 관점이 다르기 때문에 특정 세부적인 관점을 강조한다는 점에 유의하세요.

예를 들어 내 눈에 나는 돼지와 근본적으로 다른 인간이다. 같은 반 친구와 나는 같은 부류라는 점은 인정하지만 결코 그럴 수는 없다. 나와 돼지는 같은 종이라는 사실을 받아들여라. 그러나 동물학자의 눈에는 돼지와 내가 같은 종류여야 한다면, 우리는 둘 다 동물이기 때문에 "사람"과 "돼지" 모두 IAnimal 인터페이스를 구현하고 동물을 연구하고 있다고 생각할 수 있습니다 행동 그는 나와 돼지를 따로 다루지 않고 "동물"이라는 더 큰 세분화에서 연구하지만 나와 나무 사이에는 본질적인 차이가 있다고 생각할 것입니다.

이제 유전학자가 있는데 상황이 다릅니다. 모든 생물은 유전될 수 있기 때문에 그 사람 눈에는 돼지일 뿐만 아니라 모기, 박테리아, 나무, 버섯이나 SARS 바이러스 사이에는 차이가 없습니다. 왜냐하면 그는 우리 모두가 IDesc종료가능한 인터페이스(참고: 하강 vi. 상속)를 구현한다고 생각할 것이기 때문입니다. 그는 우리를 따로 연구하는 대신 모든 생물을 같은 종류로 연구할 것입니다. 그의 눈에는 인간과 바이러스 사이에는 구별이 없고 유전되는 물질과 유전되지 않는 물질만 있을 뿐입니다. 하지만 적어도 나와 돌 사이에는 차이가 있다.

그런데 어느 날 위대한 인물이 세상에 나타났습니다. 그의 이름은 레닌이었습니다. 그는 마르크스와 엥겔스의 변증법적 유물론의 걸작을 읽고 나서 유명한 정의를 내렸습니다. : 소위 실체란 의식에 의해 반영될 수 있는 객관적인 현실이다. 이 시점에서 나와 돌, 공기의 숨결, 숙어, 휴대폰 신호를 전송하는 전자기장 사이에는 아무런 차이가 없습니다. 왜냐하면 레닌의 눈에는 우리 모두가 의식에 의해 반영될 수 있는 객관적인 현실이기 때문입니다. 레닌이 프로그래머라면 그는 이렇게 말할 것입니다. 소위 문제는 "IReflectabe" 및 "IEsse" 인터페이스를 모두 구현하는 모든 클래스에 의해 생성되는 인스턴스입니다. (참고: 반영 v. 반영 esse n. 객관적 현실)

위의 예가 말도 안 된다고 생각할 수도 있지만 이것이 바로 인터페이스가 존재하는 이유입니다. 객체지향 사고의 핵심 개념 중 하나가 다형성(Polymorphism)입니다. 직설적으로 말하면, 유사한 것들은 일정한 세분성뷰 레이어에서 구분 없이 획일적으로 처리됩니다. 제가 감히 이런 일을 하는 이유는 바로 인터페이스의 존재 때문입니다. 유전학자와 마찬가지로 그는 모든 유기체가 IDescendable 인터페이스를 구현한다는 것을 이해하고 있으므로 유기체라면 Descend() 메서드가 있어야 합니다. 그래야 각 유기체를 개별적으로 연구하다가 결국 지쳐 죽는 대신 통일된 연구를 수행할 수 있습니다.

여기서 인터페이스의 성격과 기능에 대해 직관적인 인상을 줄 수는 없을 것 같습니다. 그러면 다음의 여러 디자인 패턴에 대한 예시와 분석을 통해 인터페이스가 내포하는 의미를 더욱 직관적으로 경험하게 될 것입니다.

3. 인터페이스 지향 프로그래밍 개요

그럼 인터페이스 지향 프로그래밍이란 무엇일까요? 내 개인적인 정의는 다음과 같습니다. 시스템 분석 및 아키텍처에서 레벨과 종속성을 구분합니다. 각 레벨은 상위 계층에 직접 서비스를 제공하지 않습니다. 상위 계층)) 그러나 인터페이스 세트를 정의하면 상위 계층에만 인터페이스 기능이 노출되며, 상위 계층은 하위 계층의 인터페이스에만 의존하고 특정 클래스에는 의존하지 않습니다.

이것의 장점은 무엇보다 시스템 유연성이 뛰어납니다. 하위 레이어를 변경해야 할 때 인터페이스와 인터페이스 기능이 변경되지 않는 한 상위 레이어는 수정할 필요가 없습니다. WD 60G 하드 드라이브를 Seagate 160G 하드 드라이브로 교체하는 것처럼 상위 레이어 코드를 변경하지 않고 전체 하위 레이어를 교체할 수도 있습니다. 대신 컴퓨터의 다른 부분을 변경할 필요가 없습니다. 원래 하드 드라이브를 설치하고 새 하드 드라이브를 설치하십시오. 컴퓨터의 다른 부분은 특정 하드 디스크에 의존하지 않고 IDE 인터페이스에만 의존하기 때문입니다. 교체할 수 있습니다. 여기에서 보면 프로그램 속 인터페이스가 실제 인터페이스와 매우 유사해서 인터페이스라는 단어가 정말 비슷하다는 생각을 늘 하고 있습니다!

인터페이스 사용의 또 다른 이점은 하드 디스크를 만드는 사람이 CPU나 모니터를 만드는 사람을 기다릴 필요가 없듯이 다양한 구성 요소나 수준의 개발자가 동시에 작업을 시작할 수 있다는 것입니다. 인터페이스가 일관되고 디자인이 합리적이며 전체 개발을 병렬로 수행할 수 있어 효율성이 향상됩니다.

이 기사 보충:

1. "인터페이스 지향 프로그래밍"의 "인터페이스"와 특정 개체에 대해-

의 "인터페이스"라는 단어는 친구가 "인터페이스 지향 프로그래밍"의 "인터페이스"라는 단어가 간단한 프로그래밍 언어 . 곰곰이 생각해 보니 맞는 말인 것 같습니다. 내가 여기에 쓴 내용은 참으로 불합리하다. 객체지향 언어에서 "인터페이스"는 C#에서 인터페이스 키워드로 정의된 인터페이스와 같은 특정 코드 구조를 의미한다고 생각합니다. "인터페이스 지향 프로그래밍"에서 "인터페이스"는 소프트웨어 아키텍처 관점과 보다 추상적인 수준에서 특정 기본 클래스를 숨기고 다형성을 구현하는 데 사용되는 구조적 구성 요소를 의미한다고 할 수 있습니다. 이런 의미에서 추상 클래스가 정의되고 그 목적이 다형성을 달성하는 것이라면 이 추상 클래스를 "인터페이스"라고 부르는 것이 합리적이라고 생각합니다. 하지만 다형성을 구현하기 위해 추상 클래스를 사용하는 것이 합리적일까요? 아래 두 번째 기사에서 설명합니다.

결론적으로 '인터페이스'라는 두 개념은 서로 다르면서도 연관되어 있다고 생각합니다. "인터페이스 지향 프로그래밍"의 인터페이스는 다형성을 달성하고 소프트웨어 유연성과 유지 관리성을 향상시키는 데 사용되는 이념적 아키텍처 구성 요소인 반면, 특정 언어의 "인터페이스"는 이 이념적 수준에서 구체적인 구성 요소로 구현됩니다.

2. 추상 클래스와 인터페이스에 대하여

특정 코드만 보면 이 두 개념이 모호해지기 쉽고, 심지어 인터페이스가 중복된다고 생각하기 쉽습니다. , 특정 기능만으로 판단하면 다중 상속(C#, Java의 경우) 외에도 추상 클래스가 인터페이스를 완전히 대체할 수 있는 것처럼 보이기 때문입니다. 그런데 다중상속을 구현하기 위한 인터페이스가 존재하는 걸까요? 물론 그렇지 않습니다. 제 생각에는 추상 클래스와 인터페이스의 차이점은 사용 동기에 있습니다. 추상 클래스를 사용하는 목적은 코드 재사용을 위한 것이고, 인터페이스를 사용하는 동기는 다형성을 달성하는 것입니다. 따라서 어딘가에 인터페이스를 사용할지 추상 클래스를 사용할지 결정하지 못했다면 동기를 생각해 보세요.

IPerson 인터페이스에 대해 의문을 제기하는 친구들을 보았습니다. 개인적으로 이해하기로는 IPerson 인터페이스를 정의해야 하는지 여부는 특정 애플리케이션에 따라 다릅니다. 프로젝트에 Women과 Man이 있고 둘 다 Person을 상속하고 Women과 Man의 메서드 대부분이 동일하고 DoSomethingInWC() 메서드 하나만 다르다면(예제는 다소 저속합니다. 양해해 주시기 바랍니다) 물론입니다. AbstractPerson 추상 클래스는 다른 모든 메서드를 포함할 수 있고 하위 클래스는 DoSomethingInWC()만 정의하므로 반복되는 코드의 양이 크게 줄어들기 때문에 AbstractPerson 추상 클래스를 정의하는 것이 더 합리적입니다.

但是，如果我们程序中的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) 추상 클래스에 의해 구현된 특정 메소드는 기본적으로 가상이지만 인터페이스를 구현하는 클래스의 인터페이스 메소드는 기본적으로 비가상입니다. 물론 선언할 수도 있습니다. as virtual

(9) 추상 클래스가 인터페이스를 구현하는 경우 인터페이스의 메서드를 구현할 필요 없이 추상 클래스에 추상 메서드로 매핑하고 하위 클래스의 인터페이스에 메서드를 구현할 수 있습니다. 추상 수업

위 내용은 C#의 추상 클래스와 인터페이스 간의 차이점에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!