인터페이스를 사용하는 이유는 무엇입니까?

인터페이스를 사용하는 이유는 무엇입니까?

---

나는 그들이 당신에게 방법 등을 구현하도록 강요한다는 것을 이해하지만 내가 이해할 수없는 것은 당신이 그것을 사용하려는 이유입니다. 아무도 내가 이것을 구현하고 싶은 이유에 대한 좋은 예 또는 설명을 줄 수 있습니까?

---

한 가지 구체적인 예 : 인터페이스는 다른 사람의 코드가 충족해야하는 계약을 지정하는 좋은 방법입니다.

코드 라이브러리를 작성하는 경우 특정 동작 집합을 가진 개체에 유효한 코드를 작성할 수 있습니다. 가장 좋은 해결책은 인터페이스에서 이러한 동작을 지정한 다음 (구현 없음, 설명 만) 내 라이브러리 코드에서 해당 인터페이스를 구현하는 객체에 대한 참조를 사용하는 것입니다.

그런 다음 임의의 사람이 와서 해당 인터페이스를 구현하는 클래스를 만들고 해당 클래스의 개체를 인스턴스화 한 다음 라이브러리 코드에 전달하고 작동 할 것으로 기대할 수 있습니다. 참고 : 인터페이스의 의도를 무시하면서 인터페이스를 엄격하게 구현하는 것은 물론 가능합니다. 따라서 인터페이스를 구현하는 것만으로 모든 것이 작동한다는 보장은 없습니다. 바보는 항상 방법을 찾습니다! :-)

또 다른 구체적인 예 : 협력해야하는 서로 다른 구성 요소를 작업하는 두 팀입니다. 두 팀이 1 일차에 자리를 잡고 인터페이스 세트에 동의하면 별도의 방식으로 이동하여 해당 인터페이스를 중심으로 구성 요소를 구현할 수 있습니다. 팀 A는 테스트를 위해 팀 B의 구성 요소를 시뮬레이션하는 테스트 장치를 만들 수 있으며 그 반대의 경우도 마찬가지입니다. 병렬 개발 및 더 적은 버그.

요점은 인터페이스가 추상화 계층을 제공하여 불필요한 세부 사항을 무시하는 코드를 작성할 수 있다는 것입니다.

대부분의 교과서에서 사용되는 표준 예 는 루틴 정렬입니다. 두 개체를 비교하는 방법이있는 한 모든 개체 클래스를 정렬 할 수 있습니다. 따라서 IComparable인터페이스 를 구현하여 모든 클래스를 정렬 가능하게 만들 수 있습니다. 그러면 두 인스턴스를 비교하는 메서드를 구현해야합니다. 모든 정렬 루틴은 IComparable 개체에 대한 참조를 처리하도록 작성되었으므로 IComparable을 구현하자마자 클래스의 개체 컬렉션에서 이러한 정렬 루틴을 사용할 수 있습니다.

---

인터페이스는 계약을 정의 하며 이것이 핵심 단어입니다.

프로그램에서 계약을 정의해야 할 때 인터페이스를 사용하지만 그 계약을 이행하는 클래스의 나머지 속성에 대해서는 실제로 신경 쓰지 않습니다.

그래서, 예를 봅시다. 목록을 정렬하는 기능을 제공하는 메소드가 있다고 가정하십시오. 우선 .. 목록이 무엇입니까? 목록을 정렬하기 위해 어떤 요소를 보유하고 있는지 정말 신경 쓰나요? 대답은 '아니오'여야합니다 ... .NET (예 :)에는 목록이 반드시 지원해야하는 작업을 정의하는 IList라는 인터페이스가 있으므로 표면 아래의 실제 세부 정보는 신경 쓰지 않습니다.

예를 들어, 목록에있는 개체의 클래스를 실제로 알지 못합니다. 개체를 비교할 수만 있다면 정렬하는 것이 좋습니다. 따라서 계약을 선언합니다.

interface IComparable
{
  // Return -1 if this is less than CompareWith
  // Return 0 if object are equal
  // Return 1 if CompareWith is less than this
  int Compare(object CompareWith);
}

해당 계약은 객체를 받아들이고 int를 반환하는 메서드가 비교 가능하도록 구현되어야한다고 지정합니다. 이제 계약을 정의했으며 지금은 객체 자체가 아니라 계약 에 대해 신경 쓰지 않으므로 다음과 같이 할 수 있습니다.

IComparable comp1 = list.GetItem(i) as IComparable;

if (comp1.Compare(list.GetItem(i+1)) < 0)
  swapItem(list,i, i+1)

추신 : 나는 예제가 약간 순진하지만 그들은 예제입니다 ...

---

전형적인 예는 플러그인 아키텍처입니다. 개발자 A는 기본 앱을 작성하고 개발자 B, C 및 D가 작성한 모든 플러그인이 자신의 앱에서 기대하는 바를 준수하는지 확인하려고합니다.

---

인터페이스를 이해하는 가장 쉬운 방법은 서로 다른 개체가 COMMON 기능을 노출하도록 허용하는 것입니다. 이를 통해 프로그래머는 인터페이스에 프로그래밍하는 훨씬 간단하고 짧은 코드를 작성할 수 있으며 개체가 해당 인터페이스를 구현하는 한 작동합니다.

예 1 : MySQL, MSSQL, Oracle 등 다양한 데이터베이스 공급자가 있습니다. 그러나 모든 데이터베이스 개체는 동일한 작업을 수행 할 수 있으므로 데이터베이스 개체에 대한 많은 인터페이스를 찾을 수 있습니다. 객체가 IDBConnection을 구현하면 Open () 및 Close () 메서드를 노출합니다. 따라서 내 프로그램이 데이터베이스 공급자에 구애받지 않게하려면 특정 공급자가 아닌 인터페이스에 프로그래밍합니다.

IDbConnection connection = GetDatabaseConnectionFromConfig()
connection.Open()
// do stuff
connection.Close()

인터페이스 (IDbconnection)로 프로그래밍하여보기 이제 구성에서 모든 데이터 공급자를 스왑 할 수 있지만 코드는 그대로 유지됩니다. 이러한 유연성은 매우 유용하고 유지 관리하기 쉽습니다. 이것의 단점은 내가 '일반적인'데이터베이스 작업 만 수행 할 수 있고 각 특정 공급자가 제공하는 장점을 완전히 활용하지 못할 수 있으므로 프로그래밍의 모든 부분에서 트레이드 오프가 발생하고 어떤 시나리오가 가장 도움이 될지 결정해야합니다.

예 2 :거의 모든 컬렉션이 IEnumerable이라는이 인터페이스를 구현하는 것을 알 수 있습니다. IEnumerable은 MoveNext (), Current 및 Reset ()이있는 IEnumerator를 반환합니다. 이렇게하면 C #에서 컬렉션을 쉽게 이동할 수 있습니다. 이 작업을 수행 할 수있는 이유는 IEnumerable 인터페이스를 노출하기 때문에 개체가 통과해야하는 메서드를 노출한다는 것을 알고 있기 때문입니다. 이것은 두 가지 일을합니다. 1) foreach 루프는 이제 컬렉션을 열거하는 방법을 알고 2) 이제 강력한 LINQ 표현식을 컬렉션에 적용 할 수 있습니다. 여기서도 인터페이스가 유용한 이유는 모든 컬렉션이 COMMON에 무언가를 가지고 있기 때문에 이동할 수 있기 때문입니다. 각 컬렉션은 다른 방식 (연결된 목록 대 배열)을 통해 이동할 수 있지만 인터페이스의 장점은 구현이 숨겨져 있고 인터페이스 소비자와 관련이 없다는 것입니다. MoveNext ()는 컬렉션의 다음 항목을 제공합니다. 어떻게하는지는 중요하지 않습니다. 꽤 멋지죠?

예 3 : 자신 만의 인터페이스를 디자인 할 때 한 가지 질문 만하면됩니다. 이러한 것의 공통점은 무엇입니까? 객체가 공유하는 모든 것을 찾으면 해당 속성 / 메소드를 인터페이스로 추상화하여 각 객체가 상속 할 수 있도록합니다. 그런 다음 하나의 인터페이스를 사용하여 여러 개체에 대해 프로그래밍 할 수 있습니다.

물론 제가 가장 좋아하는 C ++ 다형성 예제 인 동물 예제를 제공해야합니다. 모든 동물은 특정 특성을 공유합니다. 움직일 수 있고 말하고 모두 이름이 있다고 가정 해 봅시다. 내 모든 동물의 공통점이 무엇인지 방금 식별했기 때문에 이러한 특성을 IAnimal 인터페이스로 추상화 할 수 있습니다. 그런 다음이 인터페이스를 구현하는 Bear 개체, Owl 개체 및 Snake 개체를 만듭니다. 동일한 인터페이스를 구현하는 여러 개체를 함께 저장할 수있는 이유는 인터페이스가 IS-A 복제를 나타 내기 때문입니다. 곰은 IS-A 동물, 올빼미는 IS-A 동물이라서 모두 동물로 모을 수 있으니까요.

var animals = new IAnimal[] = {new Bear(), new Owl(), new Snake()} // here I can collect different objects in a single collection because they inherit from the same interface

foreach (IAnimal animal in animals) 
{
    Console.WriteLine(animal.Name)
    animal.Speak() // a bear growls, a owl hoots, and a snake hisses
    animal.Move() // bear runs, owl flys, snake slithers
}

이 동물들이 각각의 행동을 다른 방식으로 수행하더라도 하나의 통합 된 모델에서 그들 모두에 대해 프로그래밍 할 수 있다는 것을 알 수 있습니다. 이것은 인터페이스의 많은 이점 중 하나 일뿐입니다.

다시 말하지만 인터페이스에서 가장 중요한 것은 객체가 공통적으로 갖는 것이므로 동일한 방식으로 다른 객체에 대해 프로그래밍 할 수 있습니다. 시간을 절약하고,보다 유연한 애플리케이션을 생성하고, 복잡성 / 구현을 숨기고, 실제 개체 / 상황을 모델링하는 등 여러 이점을 제공합니다.

도움이 되었기를 바랍니다.

---

자동차의 페달은 인터페이스를 구현합니다. 나는 우리가 도로의 오른쪽에서 운전하는 미국에서 왔습니다. 우리의 스티어링 휠은 차의 왼쪽에 있습니다. 왼쪽에서 오른쪽으로 수동 변속기 용 페달은 클러치-> 브레이크-> 가속기입니다. 아일랜드에 갔을 때 운전이 반전되었습니다. 자동차의 스티어링 휠은 오른쪽에 있고 도로의 왼쪽에서 운전합니다 ...하지만 페달, 아 페달 ... 동일한 인터페이스를 구현했습니다 ... 세 개의 페달은 모두 동일한 순서였습니다 ... 그래서 클래스가 다르고 클래스가 운영하는 네트워크가 다르더라도 페달 인터페이스는 여전히 편했습니다. 내 뇌는 다른 모든 자동차와 마찬가지로이 자동차에서 내 근육을 호출 할 수있었습니다.

우리가 없이는 살 수없는 수많은 비 프로그래밍 인터페이스를 생각해보십시오. 그런 다음 자신의 질문에 답하십시오.

---

인터페이스는 다형성을 잘 활용할 것으로 예상되는 객체 지향 시스템에서 절대적으로 필요합니다.

고전적인 예는 Move () 메서드가있는 IVehicle 일 수 있습니다. IVehicle을 구현하는 Car, Bike 및 Tank 클래스를 가질 수 있습니다. 그들은 모두 Move () 할 수 있으며, 어떤 차량을 다루고 있는지 신경 쓰지 않는 코드를 작성할 수 있습니다. Move () 할 수 있습니다.

void MoveAVehicle(IVehicle vehicle)
{
    vehicle.Move();
}

---

When you need different classes to share same methods you use Interfaces.

---

인터페이스는 다형성의 한 형태입니다. 예 :

로깅 코드를 작성한다고 가정 해 보겠습니다. 로깅은 어딘가 (파일, 메인 코드가 실행되는 장치의 직렬 포트, 소켓 또는 / dev / null처럼 버려짐)로 이동합니다. 당신은 어디에 있는지 모릅니다 : 당신의 로깅 코드의 사용자는 그것을 결정할 자유가 있어야합니다. 사실, 로깅 코드는 상관하지 않습니다. 단지 바이트를 쓸 수있는 무언가를 원합니다.

그래서 "바이트를 쓸 수있는 것"이라는 인터페이스를 발명합니다. 로깅 코드에는이 인터페이스의 인스턴스가 제공됩니다 (아마도 런타임시, 컴파일시 구성 될 수 있습니다. 여전히 다형성이며 다른 종류 일뿐입니다). 인터페이스를 구현하는 하나 이상의 클래스를 작성하고 로깅 코드가 사용할 클래스를 변경하여 로깅 위치를 쉽게 변경할 수 있습니다. 다른 사람은 코드를 변경하지 않고 인터페이스의 자체 구현을 작성하여 로깅 위치를 변경할 수 있습니다. 그것이 기본적으로 다형성에 해당하는 것입니다. 특정 방식으로 사용하기 위해 객체에 대해 충분히 알고 있으면서도 알 필요가없는 모든 측면에서 달라질 수 있습니다. 인터페이스는 알아야 할 사항을 설명합니다.

C의 파일 디스크립터는 기본적으로 "내가 읽고 / 또는 바이트를 쓸 수있는"인터페이스이며, 거의 모든 형식화 된 언어에는 스트림 등의 표준 라이브러리에 이러한 인터페이스가 숨어 있습니다. 형식화되지 않은 언어에는 일반적으로 스트림을 나타내는 비공식 형식 (계약이라고도 함)이 있습니다. 따라서 실제로는이 특정 인터페이스를 실제로 직접 발명 할 필요가 거의 없습니다. 언어가 제공하는 것을 사용합니다.

로깅과 스트림은 한 가지 예일뿐입니다. 인터페이스는 객체가 수행해야하는 작업을 추상적 인 용어로 설명 할 수있을 때마다 발생하지만 특정 구현 / 클래스 / 무엇이든 연결하고 싶지는 않습니다.

---

그렇게하는 데는 여러 가지 이유가 있습니다. 인터페이스를 사용하면 나중에 코드를 리팩터링 / 재 작성해야 할 준비가 된 것입니다. 간단한 작업을 위해 일종의 표준화 된 API를 제공 할 수도 있습니다.

예를 들어 빠른 정렬과 같은 정렬 알고리즘을 작성하려는 경우 개체 목록을 정렬하는 데 필요한 것은 두 개체를 성공적으로 비교할 수 있다는 것입니다. 인터페이스를 만들면 개체를 만드는 사람이 ISortable 인터페이스를 구현할 수 있고 정렬 코드를 사용할 수 있습니다.

데이터베이스 스토리지를 사용하는 코드를 작성하고 스토리지 인터페이스에 작성하는 경우 해당 코드를 바로 바꿀 수 있습니다.

인터페이스는 더 큰 유연성을 가질 수 있도록 코드의 느슨한 결합을 권장합니다.

---

기본 CRUD 메커니즘을 정의하는 다음 기본 인터페이스를 상상해보십시오.

interface Storable {
    function create($data);
    function read($id);
    function update($data, $id);
    function delete($id);
}

From this interface, you can tell that any object that implements it, must have functionality to create, read, update and delete data. This could by a database connection, a CSV file reader, and XML file reader, or any other kind of mechanism that might want to use CRUD operations.

Thus, you could now have something like the following:

class Logger {
    Storable storage;

    function Logger(Storable storage) {
        this.storage = storage;
    }

    function writeLogEntry() {
        this.storage.create("I am a log entry");
    }
}

This logger doesn't care if you pass in a database connection, or something that manipulates files on disk. All it needs to know is that it can call create() on it, and it'll work as expected.

The next question to arise from this then is, if databases and CSV files, etc, can all store data, shouldn't they be inherited from a generic Storable object and thus do away with the need for interfaces? The answer to this is no... not every database connection might implement CRUD operations, and the same applies to every file reader.

Interfaces define what the object is capable of doing and how you need to use it... not what it is!

---

The best Java code I have ever seen defined almost all object references as instances of interfaces instead of instances of classes. It is a strong sign of quality code designed for flexibility and change.

---

As you noted, interfaces are good for when you want to force someone to make it in a certain format.

Interfaces are good when data not being in a certain format can mean making dangerous assumptions in your code.

For example, at the moment I'm writing an application that will transform data from one format in to another. I want to force them to place those fields in so I know they will exist and will have a greater chance of being properly implemented. I don't care if another version comes out and it doesn't compile for them because it's more likely that data is required anyways.

Interfaces are rarely used because of this, since usually you can make assumptions or don't really require the data to do what you need to do.

---

An interface, defines merely the interface. Later, you can define method (on other classes), which accepted interfaces as parameters (or more accurately, object which implement that interface). This way your method can operate on a large variety of objects, whose only commonality is that they implement that interface.

---

First, they give you an additional layer of abstraction. You can say "For this function, this parameter must be an object that has these methods with these parameters". And you probably want to also set the meaning of these methods, in somehow abstracted terms, yet allowing you to reason about the code. In duck-typed languages you get that for free. No need for explicit, syntax "interfaces". Yet you probably still create a set of conceptual interfaces, something like contracts (like in Design by Contract).

Furthermore, interfaces are sometimes used for less "pure" purposes. In Java, they can be used to emulate multiple inheritance. In C++, you can use them to reduce compile times.

In general, they reduce coupling in your code. That's a good thing.

Your code may also be easier to test this way.

---

Let's say you want to keep track of a collection of stuff. Said collections must support a bunch of things, like adding and removing items, and checking if an item is in the collection.

You could then specify an interface ICollection with the methods add(), remove() and contains().

Code that doesn't need to know what kind of collection (List, Array, Hash-table, Red-black tree, etc) could accept objects that implemented the interface and work with them without knowing their actual type.

---

In .Net, I create base classes and inherit from them when the classes are somehow related. For example, base class Person could be inherited by Employee and Customer. Person might have common properties like address fields, name, telephone, and so forth. Employee might have its own department property. Customer has other exclusive properties.

Since a class can only inherit from one other class in .Net, I use interfaces for additional shared functionality. Sometimes interfaces are shared by classes that are otherwise unrelated. Using an interface creates a contract that developers will know is shared by all of the other classes implementing it. I also forces those classes to implement all of its members.

---

In an article in my blog I briefly describe three purposes interfaces have.

Interfaces may have different purposes:

• Provide different implementations for the same goal. The typical example is a list, which may have different implementations for different performance use cases (LinkedList, ArrayList, etc.).
• Allow criteria modification. For example, a sort function may accept a Comparable interface in order to provide any kind of sort criteria, based on the same algorithm.
• Hide implementation details. This also makes it easier for a user to read the comments, since in the body of the interface there are only methods, fields and comments, no long chunks of code to skip.

Here's the article's full text: http://weblogs.manas.com.ar/ary/2007/11/

---

In C# interfaces are also extremely useful for allowing polymorphism for classes that do not share the same base classes. Meaning, since we cannot have multiple inheritance you can use interfaces to allow different types to be used. It's also a way to allow you to expose private members for use without reflection (explicit implementation), so it can be a good way to implement functionality while keeping your object model clean.

For example:

public interface IExample
{
    void Foo();
}

public class Example : IExample
{
    // explicit implementation syntax
    void IExample.Foo() { ... }
}

/* Usage */
Example e = new Example();

e.Foo(); // error, Foo does not exist

((IExample)e).Foo(); // success

---

I think you need to get a good understand of design patterns so see there power.

Check out Head First Design Patterns

참고URL : https://stackoverflow.com/questions/240152/why-would-i-want-to-use-interfaces