객체 지향 프로그래밍에서 "인터페이스"의 정의는 무엇입니까?

객체 지향 프로그래밍에서 "인터페이스"의 정의는 무엇입니까?

---

좋아, 내 친구가 프로그래밍에서 "인터페이스"가 의미하는 바를 앞뒤로 설명합니다.

"인터페이스"에 대한 가장 좋은 설명은 무엇입니까?

나에게 인터페이스는 클래스의 청사진입니다. 이것이 가장 좋은 정의입니까?

---

인터페이스는 개발 과정에서 과부하되고 혼란스러운 용어 중 하나입니다.

실제로 추상화와 캡슐화의 개념입니다. 주어진 "상자"에 대해 해당 상자 의 "입력"및 "출력"을 선언 합니다. 소프트웨어 세계에서 이는 일반적으로 상자에서 (인수와 함께) 호출 할 수있는 작업과 경우에 따라 이러한 작업의 반환 유형을 의미합니다.

이것이하지 않는 것은 이러한 연산의 의미가 무엇인지 정의하는 것입니다. 그러나 선언에 근접하여 (예 : 주석을 통해) 문서화하거나 좋은 명명 규칙을 선택하는 것이 일반적이고 (매우 좋은 관행)이지만. 그럼에도 불구하고 이러한 의도를 따를 것이라는 보장은 없습니다.

비유는 다음과 같습니다. TV가 꺼져있을 때 TV를 살펴보십시오. 인터페이스는 버튼, 다양한 플러그 및 화면입니다. 의미와 동작은 입력 (예 : 케이블 프로그래밍)을 받고 출력 (화면 표시, 사운드 등)을 갖는다는 것입니다. 그러나 연결되지 않은 TV를 보면 예상되는 의미를 인터페이스에 투영하는 것입니다. 아시다시피 TV는 플러그를 꽂으면 폭발 할 수 있습니다. 그러나 "인터페이스"에 따르면 물을 마시지 않기 때문에 커피를 만들지 않을 것이라고 가정 할 수 있습니다.

객체 지향 프로그래밍에서 인터페이스는 일반적으로 해당 인터페이스가있는 클래스의 인스턴스가 응답 할 수있는 메서드 (또는 메시지) 집합을 정의합니다.

혼란을 더하는 것은 Java와 같은 일부 언어에는 언어 별 의미 체계를 가진 실제 인터페이스가 있다는 것입니다. 예를 들어 Java에서는 구현이없는 메서드 선언 집합이지만 인터페이스도 유형에 해당하고 다양한 입력 규칙을 따릅니다.

C ++와 같은 다른 언어에서는 인터페이스가 없습니다. 클래스 자체는 메서드를 정의하지만 클래스의 인터페이스를 비공개 메서드의 선언으로 생각할 수 있습니다. C ++ 컴파일 방식으로 인해 실제 구현없이 클래스의 "인터페이스"를 가질 수있는 헤더 파일을 얻을 수 있습니다. 순수 가상 함수 등을 사용하여 추상 클래스로 Java 인터페이스를 모방 할 수도 있습니다.

인터페이스는 확실히 클래스의 청사진이 아닙니다. 하나의 정의에 따르면 청사진은 "상세한 행동 계획"입니다. 인터페이스는 행동에 대해 아무것도 약속하지 않습니다! 혼란의 원인은 대부분의 언어에서 일련의 메소드를 정의하는 인터페이스 유형이있는 경우이를 구현하는 클래스가 동일한 메소드를 "반복"하므로 (정의를 제공함) 인터페이스가 골격 또는 수업 개요.

---

다음 상황을 고려하십시오.

좀비가 갑자기 당신을 공격 할 때 당신은 크고 빈 방 한가운데에 있습니다.

무기가 없습니다.

운 좋게도, 살아있는 동료가 방의 출입구에 서 있습니다.

"빨리!" 당신은 그에게 소리 친다. "좀비를 때릴 수있는 걸 던져 줘!"

이제 생각해보십시오 :
당신은 당신의 친구가 던지기로 선택하는 것을 정확히 지정하지 않았습니다 .
...하지만 다음과 같은 경우에는 중요하지 않습니다.

• 그것은의 뭔가 수 있습니다 던져 수 (그는 당신에게 소파를 던져 수 없습니다)

• 잡을 수있는 것 (수리검을 던지지 않았 으면 좋겠어)

• 좀비의 두뇌를 쫓아내는 데 사용할 수있는 것입니다 (베개 등을 배제합니다)

야구 방망이를 얻든 망치를 얻든 상관 없습니다.
세 가지 조건을 충족하는 한 당신은 좋습니다.

그것을 요 ​​약하기:

인터페이스를 작성할 때 기본적으로 "나는 무언가가 필요해 ..."라고 말합니다.

---

인터페이스는 구현 자인지 사용자인지에 따라 준수하거나 제공해야하는 계약입니다.

---

나는 "청사진"이 사용하기에 좋은 단어라고 생각하지 않는다. 청사진은 무언가를 만드는 방법을 알려줍니다. 인터페이스는 특히 무언가를 만드는 방법을 알려주지 않습니다.

인터페이스는 클래스와 상호 작용할 수있는 방법, 즉 지원하는 메서드를 정의합니다.

---

나에게 인터페이스는 클래스의 청사진입니다. 이것이 가장 좋은 정의입니까?

아니요. 청사진에는 일반적으로 내부가 포함됩니다. 그러나 인터페이스는 순전히 클래스 외부에서 볼 수있는 것에 관한 것입니다. 더 정확하게는 인터페이스를 구현하는 클래스 패밀리입니다.

인터페이스는 메소드의 시그니처와 상수 값, 그리고 인터페이스를 구현하는 클래스와이를 사용하는 다른 클래스 간의 (일반적으로 비공식적 인) "동작 계약"으로 구성됩니다.

---

프로그래밍에서 인터페이스는 객체가 가질 동작을 정의하지만 실제로 동작을 지정하지는 않습니다. 특정 클래스가 무언가를 할 수 있다는 것을 보증하는 계약입니다.

여기에서이 C # 코드를 고려하십시오.

using System;

public interface IGenerate
{
    int Generate();
}

// Dependencies
public class KnownNumber : IGenerate
{
    public int Generate() 
    {
        return 5;
    }   
}

public class SecretNumber : IGenerate
{
    public int Generate()
    {
        return new Random().Next(0, 10);
    }
}

// What you care about
class Game
{
    public Game(IGenerate generator) 
    {
        Console.WriteLine(generator.Generate())
    }
}

new Game(new SecretNumber());
new Game(new KnownNumber());

Game 클래스에는 비밀 번호가 필요합니다. 이를 테스트하기 위해 비밀 번호로 사용될 정보를 삽입하려고합니다 (이 원칙을 Inversion of Control이라고 함).

게임 클래스는 실제로 난수를 생성하는 것에 대해 "열린 마음"을 갖기를 원하므로 생성자에서 "Generate 메서드가있는 모든 것"을 요청합니다.

First, the interface specifies, what operations an object will provide. It just contains what it looks like, but no actual implementation is given. This is just the signature of the method. Conventionally, in C# interfaces are prefixed with an I. The classes now implement the IGenerate Interface. This means that the compiler will make sure, that they both have a method, that returns an int and is called Generate. The game now is being called two different object, each of which implementant the correct interface. Other classes would produce an error upon building the code.

Here I noticed the blueprint analogy you used:

A class is commonly seen as a blueprint for an object. An Interface specifies something that a class will need to do, so one could argue that it indeed is just a blueprint for a class, but since a class does not necessarily need an interface, I would argue that this metaphor is breaking. Think of an interface as a contract. The class that "signs it" will be legally required (enforced by the compiler police), to comply to the terms and conditions in the contract. This means that it will have to do, what is specified in the interface.

This is all due to the statically typed nature of some OO languages, as it is the case with Java or C#. In Python on the other hand, another mechanism is used:

import random

# Dependencies
class KnownNumber(object):
    def generate(self):
        return 5

class SecretNumber(object):
    def generate(self):
        return random.randint(0,10)

# What you care about
class SecretGame(object):
    def __init__(self, number_generator):
        number = number_generator.generate()
        print number

Here, none of the classes implement an interface. Python does not care about that, because the SecretGame class will just try to call whatever object is passed in. If the object HAS a generate() method, everything is fine. If it doesn't: KAPUTT! This mistake will not be seen at compile time, but at runtime, so possibly when your program is already deployed and running. C# would notify you way before you came close to that.

The reason this mechanism is used, naively stated, because in OO languages naturally functions aren't first class citizens. As you can see, KnownNumber and SecretNumber contain JUST the functions to generate a number. One does not really need the classes at all. In Python, therefore, one could just throw them away and pick the functions on their own:

# OO Approach
SecretGame(SecretNumber())
SecretGame(KnownNumber())

# Functional Approach

# Dependencies
class SecretGame(object):
    def __init__(self, generate):
        number =  generate()
        print number

SecretGame(lambda: random.randint(0,10))
SecretGame(lambda: 5)

A lambda is just a function, that was declared "in line, as you go". A delegate is just the same in C#:

class Game
{
    public Game(Func<int> generate) 
    {
        Console.WriteLine(generate())
    }
}    

new Game(() => 5);
new Game(() => new Random().Next(0, 10));

The latter examples are not possible like this in Java, since Java can not jiggle around with functions as the other two (Python and C#) can. There, Interfaces are your only way of speficiying behavior this way in av.

---

Technically, I would describe an interface as a set of ways (methods, properties, accessors... the vocabulary depends on the language you are using) to interact with an object. If an object supports/implements an interface, then you can use all of the ways specified in the interface to interact with this object.

Semantically, an interface could also contain conventions about what you may or may not do (e.g., the order in which you may call the methods) and about what, in return, you may assume about the state of the object given how you interacted so far.

---

Personally I see an interface like a template. If a interface contains the definition for the methods foo() and bar(), then you know every class which uses this interface has the methods foo() and bar().

---

Let us consider a Man(User or an Object) wants some work to be done. He will contact a middle man(Interface) who will be having a contract with the companies(real world objects created using implemented classes). Few types of works will be defined by him which companies will implement and give him results. Each and every company will implement the work in its own way but the result will be same. Like this User will get its work done using an single interface. I think Interface will act as visible part of the systems with few commands which will be defined internally by the implementing inner sub systems.

---

An interface separates out operations on a class from the implementation within. Thus, some implementations may provide for many interfaces.

People would usually describe it as a "contract" for what must be available in the methods of the class.

It is absolutely not a blueprint, since that would also determine implementation. A full class definition could be said to be a blueprint.

---

An interface defines what a class that inherits from it must implement. In this way, multiple classes can inherit from an interface, and because of that inherticance, you can

• be sure that all members of the interface are implemented in the derived class (even if its just to throw an exception)
• Abstract away the class itself from the caller (cast an instance of a class to the interface, and interact with it without needing to know what the actual derived class IS)

for more info, see this http://msdn.microsoft.com/en-us/library/ms173156.aspx

---

In my opinion, interface has a broader meaning than the one commonly associated with it in Java. I would define "interface" as a set of available operations with some common functionality, that allow controlling/monitoring a module.

In this definition I try to cover both programatic interfaces, where the client is some module, and human interfaces (GUI for example).

As others already said, an interface always has some contract behind it, in terms of inputs and outputs. The interface does not promise anything about the "how" of the operations; it only guarantees some properties of the outcome, given the current state, the selected operation and its parameters.

---

As above, synonyms of "contract" and "protocol" are appropriate.

The interface comprises the methods and properties you can expect to be exposed by a class.

So if a class Cheetos Bag implements the Chip Bag interface, you should expect a Cheetos Bag to behave exactly like any other Chip Bag. (That is, expose the .attemptToOpenWithoutSpillingEverywhere() method, etc.)

---

Conventional Definition - An interface is a contract that specifies the methods which needs to be implemented by the class implementing it.

The Definition of Interface has changed over time. Do you think Interface just have method declarations only ? What about static final variables and what about default definitions after Java 5.

Interfaces were introduced to Java because of the Diamond problem with multiple Inheritance and that's what they actually intend to do.

Interfaces are the constructs that were created to get away with the multiple inheritance problem and can have abstract methods , default definitions and static final variables.

http://www.quora.com/Why-does-Java-allow-static-final-variables-in-interfaces-when-they-are-only-intended-to-be-contracts

---

A boundary across which two systems communicate.

Interfaces are how some OO languages achieve ad hoc polymorphism. Ad hoc polymorphism is simply functions with the same names operating on different types.

---

In short, The basic problem an interface is trying to solve is to separate how we use something from how it is implemented. But you should consider interface is not a contract. Read more here.

참고URL : https://stackoverflow.com/questions/2866987/what-is-the-definition-of-interface-in-object-oriented-programming