Какое определение "интерфейс" в объектно-ориентированном программировании

Хорошо, мой друг пойдет туда и обратно о том, что означает "интерфейс" в программировании.

Какое лучшее описание "интерфейса".

Для меня интерфейс - это проект класса, это лучшее определение?

Ответ 1

Интерфейс является одним из наиболее перегруженных и запутанных терминов в разработке.

Это на самом деле концепция абстракции и инкапсуляции. Для данного "ящика" он объявляет "входы" и "выходы" этого ящика. В мире программного обеспечения это обычно означает операции, которые могут быть вызваны на поле (вместе с аргументами), а в некоторых случаях возвращаемые типы этих операций.

Что он не делает, так это определяет семантику этих операций, хотя это обычное явление (и очень хорошая практика) документировать их в непосредственной близости от объявления (например, с помощью комментариев) или выбирать хорошие соглашения об именах. Тем не менее, нет никаких гарантий, что эти намерения будут выполнены.

Вот аналогия: посмотрите на телевизор, когда он выключен. Его интерфейс - это кнопки, различные разъемы и экран. Его семантика и поведение заключаются в том, что он принимает входы (например, программирование кабеля) и имеет выходы (отображение на экране, звук и т.д.). Однако, когда вы смотрите на телевизор, который не подключен, вы проецируете ожидаемую семантику в интерфейс. Насколько вы знаете, телевизор может просто взорваться, когда вы подключите его к сети. Однако, основываясь на его "интерфейсе", вы можете предположить, что он не будет готовить кофе, поскольку в нем нет воды.

В объектно-ориентированном программировании интерфейс обычно определяет набор методов (или сообщений), на которые может реагировать экземпляр класса, имеющий этот интерфейс.

Что добавляет путаницу, так это то, что в некоторых языках, таких как Java, существует реальный интерфейс с его языковой семантикой. В Java, например, это набор объявлений методов, без реализации, но интерфейс также соответствует типу и подчиняется различным правилам типизации.

В других языках, таких как C++, у вас нет интерфейсов. Класс сам определяет методы, но вы можете думать об интерфейсе класса как о объявлениях не закрытых методов. Из-за того, как C++ компилируется, вы получаете заголовочные файлы, в которых вы можете иметь "интерфейс" класса без фактической реализации. Вы также можете имитировать интерфейсы Java с абстрактными классами с чисто виртуальными функциями и т.д.

Интерфейс, безусловно, не является проектом для класса. План, по одному определению, является "подробным планом действий". Интерфейс ничего не обещает о действии! Источником путаницы является то, что в большинстве языков, если у вас есть тип интерфейса, который определяет набор методов, класс, который его реализует, "повторяет" те же методы (но предоставляет определение), поэтому интерфейс выглядит как скелет или план занятий.

Ответ 2

Рассмотрим следующую ситуацию:

Вы находитесь в середине большой пустой комнаты, когда зомби внезапно нападает на вас.

У вас нет оружия.

К счастью, в дверях комнаты стоит человек, живущий в человеке.

"Быстро!" вы кричите на него. "Бросьте мне то, с чем я могу попасть в зомби!"

Теперь рассмотрим:
Вы не указали (и не заботитесь) точно , что ваш друг решит бросить,
... Но это не имеет значения, если:

Что-то, что может быть брошено (он не может подбросить вам диван)
Это то, что вы можете схватить (пусть надеется, что он не бросил шурик)
Это то, что вы можете использовать для bash мозгов зомби (это исключает подушки и т.д.)

Не имеет значения, получаете ли вы бейсбольную биту или молот -
до тех пор, пока он реализует ваши три условия, вы хорошо.

Подводя итог:

Когда вы пишете интерфейс, вы в основном говорите: "Мне нужно что-то такое..."

Ответ 3

Интерфейс - это контракт, который вы должны соблюдать или задавать, в зависимости от того, являетесь ли вы исполнителем или пользователем.

Ответ 4

Я не думаю, что "план" - хорошее слово для использования. В плане вы узнаете, как построить что-то. Интерфейс специально избегает рассказывать вам, как что-то создавать.

Интерфейс определяет, как вы можете взаимодействовать с классом, то есть какие методы он поддерживает.

Ответ 5

Для меня интерфейс - это проект класса, это лучшее определение?

Нет. Схема обычно включает внутренние элементы. Но интерфейс - это чисто то, что видно за пределами класса... или, точнее, семейство классов, реализующих интерфейс.

Интерфейс состоит из сигнатур методов и значений констант, а также (обычно неформального) "поведенческого контракта" между классами, реализующими интерфейс, и другими, которые его используют.

Ответ 6

В программировании интерфейс определяет, какое поведение будет иметь объект, но на самом деле он не укажет поведение. Это контракт, который гарантирует, что определенный класс может что-то сделать.

Рассмотрим этот кусок кода С# здесь:

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());

Класс игры требует секретного номера. Чтобы проверить его, вы хотели бы ввести то, что будет использоваться в качестве секретного номера (этот принцип называется Inversion of Control).

Класс игры хочет быть "открытым" относительно того, что на самом деле создает случайное число, поэтому он спросит в своем конструкторе "что-нибудь, что имеет метод Generate".

Сначала интерфейс указывает, какие операции будет предоставлять объект. Он просто содержит то, на что это похоже, но фактическая реализация не предоставляется. Это всего лишь подпись метода. Обычно в интерфейсах С# префикс I. Теперь классы реализуют интерфейс IGenerate. Это означает, что компилятор удостоверится, что оба они имеют метод, который возвращает int и называется Generate. Игра теперь называется двумя разными объектами, каждый из которых реализует правильный интерфейс. Другие классы создавали ошибку при создании кода.

Здесь я заметил используемую вами аналогию:

Класс обычно рассматривается как проект для объекта. Интерфейс указывает на то, что класс должен будет делать, поэтому можно утверждать, что это действительно просто план для класса, но поскольку для класса не обязательно нужен интерфейс, я бы сказал, что эта метафора ломается. Подумайте о интерфейсе в качестве контракта. Класс, который "подписывает его", будет юридически обязательным (соблюдается полицией компилятора), чтобы соответствовать условиям контракта. Это означает, что это нужно будет сделать, что указано в интерфейсе.

Все это связано со статически типизированным характером некоторых языков OO, как в случае с Java или С#. В Python, с другой стороны, используется другой механизм:

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

Здесь ни один из классов не реализует интерфейс. Python не заботится об этом, потому что класс SecretGame будет просто пытаться вызвать любой объект. Если объект имеет метод generate(), все в порядке. Если это не так: KAPUTT! Эта ошибка не будет отображаться во время компиляции, но во время выполнения, поэтому, возможно, когда ваша программа уже развернута и запущена. С# уведомит вас, прежде чем вы приблизитесь к этому.

Причина, по которой этот механизм используется, наивно заявляется, потому что в языках OO естественным образом функции не являются первоклассными гражданами. Как вы можете видеть, KnownNumber и SecretNumber содержат JUST функции для генерации числа. На самом деле не нужны классы вообще. Поэтому в Python можно просто выбросить их и самостоятельно выбрать функции:

# 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)

Лямбда - это просто функция, которая была объявлена "в строке, когда вы идете". Делегат в С# является тем же самым:

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

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

Последние примеры невозможны в Java, так как Java не может перемещаться с функциями, как другие два (Python и С#). Там Интерфейсы - ваш единственный способ описать поведение таким образом в av.

Ответ 7

Технически я бы описал интерфейс как набор способов (методы, свойства, аксессоры... словарь зависит от языка, который вы используете) для взаимодействия с объектом. Если объект поддерживает/реализует интерфейс, то вы можете использовать все способы, указанные в интерфейсе, для взаимодействия с этим объектом.

Семантически, интерфейс может также содержать соглашения о том, что вы можете или не можете сделать (например, порядок, в котором вы можете назвать методы), и о том, что, в свою очередь, вы можете предположить о состоянии объекта, учитывая, как вы взаимодействовали до сих пор.

Ответ 8

Лично я вижу интерфейс, как шаблон. Если интерфейс содержит определение для методов foo() и bar(), то вы знаете, что каждый класс, который использует этот интерфейс, имеет методы foo() и bar().

Ответ 9

Давайте рассмотрим человека (пользователя или объекта), который хочет выполнить некоторую работу. Он свяжется со средним человеком (Interface), у которого будет контракт с компаниями (объекты реального мира, созданные с использованием реализованных классов). Немногие виды работ будут определены им, какие компании будут внедрять и дать ему результаты. Каждая компания будет выполнять свою работу по-своему, но результат будет таким же. Подобно этому пользователю будет выполнена его работа с использованием одного интерфейса. Я думаю, что Интерфейс будет действовать как видимая часть систем с несколькими командами, которые будут определяться внутренне внутренними подсистемами реализации.

Ответ 10

Интерфейс отделяет операции над классом от реализации внутри. Таким образом, некоторые реализации могут обеспечить множество интерфейсов.

Люди обычно описывают это как "контракт" для того, что должно быть доступно в методах класса.

Это абсолютно не проект, так как это также будет определять реализацию. Полное определение класса можно назвать планом.

Ответ 11

Интерфейс определяет то, что должен реализовать класс, который наследует от него. Таким образом, несколько классов могут наследовать от интерфейса, и из-за этой способности вы можете

убедитесь, что все члены интерфейса реализованы в производном классе (даже если он просто выбрал исключение)
Откажитесь от самого класса от вызывающего (приведите экземпляр класса к интерфейсу и взаимодействуйте с ним, не зная, что такое фактический производный класс IS)

для получения дополнительной информации см. этот http://msdn.microsoft.com/en-us/library/ms173156.aspx

Ответ 12

По-моему, интерфейс имеет более широкий смысл, чем тот, который обычно ассоциируется с ним в Java. Я бы определил "интерфейс" как набор доступных операций с некоторыми общими функциональными возможностями, которые позволяют контролировать/контролировать модуль.

В этом определении я пытаюсь охватить как программные интерфейсы, где клиент является некоторым модулем, так и человеческими интерфейсами (например, GUI).

Как уже говорили другие, интерфейс всегда имеет за собой какой-то контракт с точки зрения входов и выходов. Интерфейс ничего не обещает "как" операций; это только гарантирует некоторые свойства результата, учитывая текущее состояние, выбранную операцию и ее параметры.

Ответ 13

Как и выше, синонимы "контракта" и "протокола" являются подходящими.

Интерфейс содержит методы и свойства, которые вы можете ожидать от класса.

Итак, если класс Cheetos Bag реализует интерфейс Chip Bag, вы должны ожидать, что Cheetos Bag будет вести себя точно так же, как и любой другой Chip Bag. (То есть, выведите метод .attemptToOpenWithoutSpillingEverywhere() и т.д.)

Ответ 14

Обычное определение. Интерфейс - это контракт, который определяет методы, которые должны быть реализованы классом, реализующим его.

Определение интерфейса со временем изменилось. Считаете ли вы, что интерфейс имеет только объявления методов? Как насчет статических конечных переменных и о определениях по умолчанию после Java 5.

Интерфейсы были введены в Java из-за проблемы Diamond с множественным наследованием и того, что они на самом деле намерены делать.

Интерфейсы - это конструкции, которые были созданы для устранения проблемы множественного наследования и могут иметь абстрактные методы, определения по умолчанию и статические конечные переменные.

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

Ответ 15

Граница, через которую взаимодействуют две системы.

Интерфейсы - это то, как некоторые языки OO достигают ad hoc polymorphism. Ad hoc-полиморфизм - это просто функции с теми же именами, которые работают на разных типах.

Ответ 16

интерфейс - это "какая работа", метод не "как". Это контракт. Как в очереди с приоритетом, вы знаете, что с ним делать, но основную реализацию вы не знаете. Класс соглашается никогда изменить "эффекты" существующих операций, и клиент соглашается использовать класса строго на основе его интерфейса и игнорировать любую реализацию подробности.

Лаймен, например: Подумайте о том, чтобы иметь универсальный пульт, который может управлять любым телевизором, будь то модель старой трубки или та, которая использует ЖК-дисплей или плазменный экран. Вы нажимаете 2, затем 5, затем Enter, и на любом из экранов будет отображаться канал 25, даже несмотря на то, что механизм, позволяющий сделать это, значительно отличается в зависимости от о базовой технологии.

Ответ 17

Короче говоря, основная проблема, которую пытается решить интерфейс, - это отделить то, как мы используем что-то от того, как это реализовано. Но вы должны учитывать, что интерфейс не является контрактом. Узнайте больше здесь.