인터페이스와 클래스의 차이점은 무엇이며 클래스에서 직접 메서드를 구현할 수 있는데 인터페이스를 사용해야하는 이유는 무엇입니까?

인터페이스와 클래스의 차이점은 무엇이며 클래스에서 직접 메서드를 구현할 수 있는데 인터페이스를 사용해야하는 이유는 무엇입니까?

---

나는 이것이 매우 기본적인 질문이라는 것을 알고 있지만 면접관이 매우 속임수로 내게 물었고 나는 무력했습니다.

저는 인터페이스에 대한 물질적 또는 이론적 정의 만 알고 있으며 제가 작업 한 많은 프로젝트에서도 구현했습니다. 그러나 나는 이것이 왜 그리고 어떻게 유용한 지 이해하지 못합니다.

나는 또한 인터페이스에서 한 가지를 이해하지 못합니다. 예를 들어, 우리는

conn.Dispose();드디어 블록에서. 하지만 클래스가 IDisposable인터페이스 ( SqlConnection) 클래스를 구현하거나 상속하고 있다는 것을 알지 못합니다 . 메서드 이름을 어떻게 호출 할 수 있는지 궁금합니다. 또한 마찬가지로 Dispose 메서드가 작동하는 방식을 이해하지 못합니다. 모든 인터페이스 메서드에 대해 자체 구현으로 함수 본문을 구현해야하기 때문입니다. 그렇다면 인터페이스는 어떻게 수락되거나 계약으로 명명됩니까? 이 질문들은 지금까지 내 마음 속에 계속 떠 올랐고 솔직히 내가 이해할 수있는 방식으로 내 질문을 설명 할 좋은 스레드를 본 적이 없었습니다.

평소와 같이 MSDN은 매우 무섭게 보이며 한 줄도 명확하지 않습니다 ( 고급 개발에 참여하는 사람들, 친절하게도 변명합니다. 어떤 코드 나 기사도 그것을 보는 사람의 마음에 닿아 야한다고 강하게 느낍니다. 따라서 다른 많은 사람들이 말하는 것처럼 MSDN 사용하지 않습니다 ).

면접관은 다음과 같이 말했습니다.

그는 5 개의 메소드를 가지고 있으며 클래스에서 직접 구현하는 것을 기쁘게 생각합니다.하지만 Abstract 클래스 나 인터페이스로 가야한다면 어떤 것을 선택하고 그 이유는 무엇입니까? 나는 추상 클래스와 인터페이스의 장점과 단점을 여러 블로그에서 읽은 모든 것에 대답했지만 그는 확신하지 못하고 "Why Interface"를 일반적으로 이해하려고 노력하고있다. 일반적으로 동일한 메서드를 한 번만 구현할 수 있고 변경하지 않아도 "Why abstract class".

인터넷에서 인터페이스와 그 기능에 대해 명확하게 설명하는 기사를 얻을 수 있습니다. 나는 여전히 인터페이스에 대해 모르지만 (나는 내가 사용한 이론과 방법을 알고있다) 그 많은 프로그래머 중 한 명이지만 내가 그것을 명확하게 이해했다는 것에 만족하지 않는다.

---

인터페이스는 다음과 같은 것을 만들고 싶을 때 탁월합니다.

using System;

namespace MyInterfaceExample
{
    public interface IMyLogInterface
    {
        //I want to have a specific method that I'll use in MyLogClass
        void WriteLog();       
    }

    public class MyClass : IMyLogInterface
    {

        public void WriteLog()
        {
            Console.Write("MyClass was Logged");
        }
    }

    public class MyOtherClass : IMyLogInterface
    {

        public void WriteLog()
        {
            Console.Write("MyOtherClass was Logged");
            Console.Write("And I Logged it different, than MyClass");
        }
    }

    public class MyLogClass
    {
        //I created a WriteLog method where I can pass as a parameter any object that implements IMyLogInterface.
        public static void WriteLog(IMyLogInterface myLogObject)
        {
            myLogObject.WriteLog(); //So I can use WriteLog here.
        }
    }

    public class MyMainClass
    {
        public void DoSomething()
        {
            MyClass aClass = new MyClass();
            MyOtherClass otherClass = new MyOtherClass();

            MyLogClass.WriteLog(aClass);//MyClass can log, and have his own implementation
            MyLogClass.WriteLog(otherClass); //As MyOtherClass also have his own implementation on how to log.
        }
    }
}

제 예에서 저는을 작성하는 개발자가 될 수 있고 MyLogClass다른 개발자는 클래스를 생성 할 수 있으며 로깅을 원할 때 인터페이스를 구현할 수 있습니다 IMyLogInterface. WriteLog()에서 메소드 를 사용 하기 위해 구현해야하는 것이 무엇인지 묻는 것 입니다 MyLogClass. 인터페이스에서 찾을 수있는 답입니다.

---

인터페이스를 사용하는 한 가지 이유는 코드의 유연성을 높이기 때문입니다. 다음과 같이 Account 클래스 유형의 객체를 매개 변수로 취하는 메소드가 있다고 가정 해 보겠습니다.

public void DoSomething(Account account) {
  // Do awesome stuff here.
}

이것의 문제는 메소드 매개 변수가 계정의 구현에 고정된다는 것입니다. 다른 유형의 계정이 필요하지 않은 경우 괜찮습니다. 대신 계정 인터페이스를 매개 변수로 사용하는이 예제를 사용하십시오.

public void DoSomething(IAccount account) {
  // Do awesome stuff here.
}

이 솔루션은 구현에 고정되어 있지 않습니다. 즉, SuperSavingsAccount 또는 ExclusiveAccount (둘 다 IAccount 인터페이스 구현)를 전달하고 구현 된 각 계정에 대해 다른 동작을 얻을 수 있습니다.

---

인터페이스 는 구현자가 따라야하는 계약입니다. 추상 클래스 는 계약과 공유 구현을 허용합니다. 인터페이스는 가질 수 없습니다. 클래스는 여러 인터페이스를 구현하고 상속 할 수 있습니다. 클래스는 하나의 추상 클래스 만 확장 할 수 있습니다.

왜 인터페이스인가

• 기본 또는 공유 코드 구현이 없습니다.
• 데이터 계약 (웹 서비스, SOA)을 공유하려는 경우
• 각 인터페이스의 구현에 대해 서로 다른 구현을 (가지고 IDbCommand있습니다 SqlCommand및 OracleCommand특정의 방법으로 인터페이스를 구현하는 )
• 다중 상속 을 지원 하려고합니다 .

왜 추상인가

• 기본 또는 공유 코드 구현이 있습니다.
• 코드 중복을 최소화하려는 경우
• 버전 관리 를 쉽게 지원 하고 싶습니다.

---

따라서이 예제에서 PowerSocket은 다른 개체에 대해 아무것도 알지 못합니다. 개체는 모두 PowerSocket에서 제공하는 Power에 의존하므로 IPowerPlug를 구현하고 그렇게하여 연결할 수 있습니다.

인터페이스는 객체가 서로에 대해 알 필요없이 함께 작동하는 데 사용할 수있는 계약을 제공하기 때문에 유용합니다.

---

한마디로- 다형성 때문에 !

"구현이 아닌 인터페이스로 프로그래밍"하면 동일한 인터페이스 (유형)를 공유하는 다른 객체를 메소드에 인자로 주입 할 수 있습니다. 이렇게하면 메서드 코드가 다른 클래스의 구현과 결합되지 않습니다. 즉, 동일한 인터페이스의 새로 생성 된 객체에 대해 작업 할 수 있도록 항상 열려 있습니다. (개폐 원칙)

• Dependency Injection을 살펴보고 Design Patterns-Elements of Reusable Object-Oriented Software by GOF를 읽어보십시오 .

---

C #에는 덕 타이핑이 없습니다. 특정 메서드가 구체적인 클래스 집합에 구현되어 있다는 것을 알고 있다고해서 해당 메서드 호출과 관련하여 모두 동일하게 처리 할 수 ​​있다는 의미는 아닙니다. 인터페이스를 구현하면 인터페이스가 정의하는 것과 관련하여 인터페이스를 구현하는 모든 클래스를 동일한 유형으로 취급 할 수 있습니다.

---

인터페이스를 사용하여 다음을 수행 할 수 있습니다.

1) 구현의 다른 부분을 제공하는 분리 된 인터페이스를 생성하여보다 일관된 인터페이스를 허용합니다.

2) 인터페이스간에 동일한 이름을 가진 여러 메서드를 허용합니다. 구현이 충돌하지 않고 서명 만 있기 때문입니다.

3) 구현과 독립적으로 인터페이스를 버전 화하고 하이브하여 계약이 충족되도록 할 수 있습니다.

4) 코드는 구체화보다는 추상화에 의존 할 수 있으므로 테스트 Mocks 주입 등 스마트 종속성 주입이 가능합니다.

내가 확신하는 더 많은 이유가 있습니다.

추상 클래스를 사용하면 작업 할 부분적으로 구체적인 기반을 가질 수 있습니다. 이것은 인터페이스와 동일하지 않지만 템플릿 메서드 패턴을 사용하여 부분 구현을 만드는 기능과 같은 고유 한 특성을 가지고 있습니다.

---

이 질문에 이미 많은 피가 흘렀다 고 생각하며, 많은 사람들은 일반인이 이해할 수없는 로봇과 같은 용어를 설명함으로써이 문제를 해결하려고합니다.

그래서 먼저. 인터페이스와 추상이 무엇인지 알아야하는 이유를 알 수 있습니다. 저는 팩토리 클래스를 신청할 때이 두 가지를 개인적으로 배웠습니다. 이 링크 에서 좋은 자습서를 찾습니다.

이제 내가 이미 준 링크를 기반으로 파헤쳐 보겠습니다.

사용자 요구 사항에 따라 변경 될 수있는 Vehicle 클래스가 있습니다 (예 : Truck , Tank , Airplane 등).

public class clsBike:IChoice
{
   #region IChoice Members
    public string Buy()
    {
       return ("You choose Bike");
    }
    #endregion
}

과

public class clsCar:IChoice
{
   #region IChoice Members
    public string Buy()
    {
       return ("You choose Car");
    }
    #endregion
}

둘 다 내 클래스에 Buy 메서드가 있어야한다고 말하는 Contract IChoice가 있습니다.

public interface IChoice
{
    string Buy();
}

이제 그 인터페이스는 메소드 만 적용 Buy()하지만 상속 된 클래스가 구현할 때 수행 할 작업을 결정하도록합니다. 이것은 인터페이스의 한계입니다. 순수하게 인터페이스를 사용하면 abstact를 사용하여 자동으로 구현할 수있는 일부 작업을 반복 할 수 있습니다. 예를 들어 각 차량을 구매하면 할인이 적용됩니다.

public abstract class Choice
{
    public abstract string Discount { get; }
    public abstract string Type { get; }
    public string Buy()
    {
       return "You buy" + Type + " with " + Discount;
}
public class clsBike: Choice
{
    public abstract string Discount { get { return "10% Discount Off"; } }
    public abstract string Type { get { return "Bike"; } }
}

public class clsCar:Choice
{
    public abstract string Discount { get { return " $15K Less"; } }
    public abstract string Type { get { return "Car"; } }
}

이제 Factory Class를 사용하면 동일한 결과를 얻을 수 있지만 abstract를 사용하면 기본 클래스가 Buy()메서드를 실행하게합니다 .

In Summary : Interface contracts let the inherit class do the implementation while Abstract class Contracts may initialize the implementation (which can override by Inherit class)

---

As a real sample of @user2211290 answer:

Both of Array and List have interface IList. Below we have a string[] and a List<string> and make some common tests by using IList:

string[] col1 = { "zero", "one", "two", "three", "four"};
List<string> col2 = new List<string>{ "zero", "one", "two", "three"};

static void CheckForDigit(IList collection, string digit)
    {
        Console.Write(collection.Contains(digit));
        Console.Write("----");
        Console.WriteLine(collection.ToString());
    }

static void Main()
{
    CheckForDigit(col1, "one");   //True----System.String[]
    CheckForDigit(col2, "one");   //True----System.Collections.Generic.List`1[System.String]



//Another test:

    CheckForDigit(col1, "four");   //True----System.String[]
    CheckForDigit(col2, "four");   //false----System.Collections.Generic.List`1[System.String]
}

---

You can only inherit from one abstract class. You can inherit from multiple interfaces. This determines what I use for most of the cases.

The advantage of abstract class would be that you can have a base implementation. However, in the case of IDisposable, a default implementation is useless, since the base class does not know how to properly clean things up. Thus, an interface would be more suitable.

---

Both abstract class and interface are contracts.

The idea of a contract is you specify some behavior. If you say you've implemented you've agreed to the contract.

The choice of abstract over interrface is.

Any non abstract descendant of the abstract class will implement the contract.

versus

Any class that implements the interface will implement the contract.

So you use abstract when you want to specify some behavior all descendants must implement and save yourself defining a separate interface, but now everything that meets this effectively aggregated contract must be a descendant.

---

Interfaces are to make an abstraction (an archetype) of the abstraction (the classes) of the reality (the objects).

Interfaces are to specify contract terms without providing implementation provided by classes.

Interfaces are specifications:

• Interfaces are design time artifacts to specify the immobile behavior of the concept as it is alone and static.

• Classes are implementation time artifacts to specify the mobile structure of the reality as it interacts and move.

What is an interface?

When you observe a cat you can say that it is an animal that has four paws, a head, a trunk, a tail and hair. You can see that he can walk, run, eat and meow. And so on.

You have just defined an interface with its properties and its operations. As such you have not defined any modus operandi, but only features and capabilities without knowing how things work: you have defined abilities and distinctions.

As such it is not really yet a class even though in UML we call this a class in a class diagram because we can define privates and protected members to begin having a deep view of the artifact. Do not be confused here because in UML an interface is a slightly different thing that an interface in C#: it is like a partial access point to the abstraction atom. As such we said that a class can implements multiple interfaces. As such it is the same thing, but not, because interfaces in C# are both used to abstract the abstraction and to limit this abstraction as an access point. It's two different uses. Thus a class in UML represents a full coupling interface to a programming class, whereas an UML interface represents a decoupling interface of a section of a programming class. Indeed, the class diagram in UML does not take care of the implementation and all its artifacts are at the programming interface level. While we map UML classes to programming classes, it is a transposition of abstract abstraction into concrete abstraction. There is a subtlety that explains the dichotomy between the field of design and the field of programming. So a class in UML is a programming class from the point of view of a programming interface while considering inner hidden things.

Interfaces also allow to simulate multiple inheritance when not available in an awkward way. For example, the cat class will implement the cat interface that derives itself from the animal interface. This cat class will also implement these interfaces: walk, run, eat and make a sound. This compensates for the absence of multiple inheritance at the class level, but each time you need to reimplement everything and you can not factor the reality at best like the reality itself do it.

To understand that we can refer to Pascal Object coding where you define in a unit the interface and the implementation sections. In the interface you define the types and in the implementation you implement the type:

unit UnitName;

interface

type
  TheClass = class
  public
    procedure TheMethod;
  end;

implementation

class procedure TheClass.TheMethod;
begin
end;

Here, the interface section match to the UML class design while Interfaces types are thus others things.

So in our business we have one word, interface, to nominate two distinct but similar things, and it is a source of confusion.

Also in C# for example, programming interfaces allow to compensate the absence of true generic polymorphism on open types without really succeeding the goal because you lost the strongly-typed hability.

After all, interfaces are necessary to allow incompatible systems to communicate without worrying about the implementation and the management of objects in memory like introduced with the (Distributed) Common Object Model.

What is a class?

After defining a reduction of the reality from an external point of view, you can then describe it from an inside perspective: this is the class where you define data processing and message management to allow the reality you have encapsulated to come to life and interact thanks to objects using instances.

So in UML you realize a fractal immersion in the wheels of the machinery and you describe the states, the interactions and so on to be be able to implement the abstraction of the fragment of the reality you want to handle.

As such, an abstract class is somehow the equivalent of an interface from the point of view of the compiler.

More information

Protocol (object-oriented programming)

C# - Interfaces

C# - Classes

---

Interfaces allow the class designer to make the available methods very clear for the end user. They are also an integral part of polymorphism.

---

I won't post the definition of an interface against an abstract class because I think you know very well the theory and I assume you know the SOLID principles so let's get practical.

As you know interfaces cannot have any code so the dis-vantage are quite simple to understand.

if you need to initialize the property of your class providing a constructor or you want to provide part of the implementation an abstract class would be a good fit against an interface which would not allow you to do that.

So in very general you should prefer abstract class to interfaces when you need to provide a constructor or any code to the client which will inherit/extend your class

---

Abstract class are crated for related entities where as Interfaces can be used for unrelated entities.

예를 들어, Animal과 Human이라는 두 개의 엔티티가 있으면 Interface로 이동하여 Tiger, lion이라고 자세히 말하고 Animal과 연결하고 싶다면 Animal Abstract 클래스를 선택합니다.

아래와 같이 보일 것입니다

   Interface             
   ____|____
  |        |
Animal   Human



  Animal (Abstract class)
   __|___
  |      |
Tiger   Lion

참고 URL : https://stackoverflow.com/questions/10914802/what-is-the-difference-between-an-interface-and-a-class-and-why-i-should-use-an