Интерфейс (объектно-ориентированное программирование)

Возможно, эта статья содержит оригинальное исследование.

Проверьте соответствие информации приведённым источникам и удалите или исправьте информацию, являющуюся оригинальным исследованием. В случае необходимости подтвердите информацию авторитетными источниками. В противном случае статья может быть выставлена на удаление. (1 ноября 2016)

Интерфе́йс (англ. interface) — структура программы или синтаксиса, определяющая отношение с объектами, объединёнными некоторым поведением. При проектировании классов разработка интерфейса тождественна разработке спецификации (множества методов, которые каждый класс, использующий интерфейс, должен реализовывать).

Интерфейсы, наряду с абстрактными классами и протоколами, устанавливают взаимные обязательства между элементами программной системы, что является фундаментом концепции программирования по контракту (англ. design by contract, DbC). Интерфейс определяет границу взаимодействия между классами или компонентами, специфицируя определённую абстракцию, которую осуществляет реализующая сторона.

Интерфейс в ООП является строго формализованным элементом языка и широко используется в исходном коде программ.

Интерфейсы позволяют наладить множественное наследование объектов и в то же время решить проблему ромбовидного наследования. В языке C++ она решается через наследование классов с использованием ключевого слова virtual.

Описание и использование интерфейсов

Описание интерфейса, если отвлечься от деталей синтаксиса конкретных языков, состоит из двух частей: имени и методов интерфейса.

• Имя интерфейса строится по тем же правилам, что и другие идентификаторы используемого языка программирования. Разные языки и среды разработки имеют различные соглашения по оформлению кода, в соответствии с которыми имена интерфейсов могут формироваться по некоторым правилам и которые помогают отличать имя интерфейса от других идентификаторов. Например, в технологии COM и во всех поддерживающих её языках действует соглашение, согласно которому имя интерфейса строится по шаблону I<Имя>, то есть состоит из написанного с заглавной буквы осмысленного имени, которому предшествует заглавная латинская буква I (IUnknown, IDispatch, IStringList и т. п.).
• Методы интерфейса. В описании интерфейса определяются имена и сигнатуры входящих в него методов, то есть процедур или функций класса.

Использование интерфейсов возможно двумя способами:

• Класс может реализовывать интерфейс. Реализация интерфейса заключается в том, что в описании класса данный интерфейс указывается как реализуемый, а в коде класса обязательно определяются все методы, которые описаны в интерфейсе, в полном соответствии с сигнатурами из описания этого интерфейса. То есть, если класс реализует интерфейс, для любого экземпляра этого класса существуют и могут быть вызваны все описанные в интерфейсе методы. Один класс может реализовать несколько интерфейсов одновременно.
• Возможно объявление переменных и параметров методов как имеющих тип «интерфейс». В такую переменную или параметр может быть записан экземпляр любого класса, реализующего интерфейс. Если интерфейс объявлен как тип возвращаемого значения функции, это означает, что функция возвращает объект класса, реализующего данный интерфейс.

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

Таким образом, с одной стороны, интерфейс — это «договор», который обязуется выполнить класс, реализующий его, а с другой стороны, интерфейс — это тип данных, потому что его описание достаточно чётко определяет свойства объектов, чтобы наравне с классом типизировать переменные. Следует однако подчеркнуть, что интерфейс не является полноценным типом данных, так как он задаёт только внешнее поведение объектов. Внутреннюю структуру и реализацию заданного интерфейсом поведения обеспечивает класс, реализующий интерфейс; именно поэтому «экземпляров интерфейса» в чистом виде не бывает и любая переменная типа «интерфейс» содержит экземпляры конкретных классов.

Использование интерфейсов — один из вариантов обеспечения полиморфизма в объектных языках и средах. Все классы, реализующие один и тот же интерфейс с точки зрения определяемого ими поведения ведут себя внешне одинаково. Это позволяет писать обобщённые алгоритмы обработки данных, использующие в качестве типов параметры интерфейсов, и применять их к объектам различных типов.

Например, интерфейс Cloneable может описать абстракцию клонирования (создания точных копий) объектов, специфицировав метод Clone, который должен выполнять копирование содержимого объекта в другой объект того же типа. Тогда любой класс, объекты которого может понадобиться копировать, должен реализовать интерфейс Cloneable и предоставить метод Clone, а в любом месте программы, где требуется клонирование объектов, для этой цели у объекта вызывается метод Clone. Причём использующему этот метод коду достаточно иметь только описание интерфейса, он может ничего не знать о фактическом классе, объекты которого копируются. Таким образом, интерфейсы позволяют разбить программную систему на модули без взаимной зависимости кода.

Что может и что не может содержать интерфейс

«Чистый» интерфейс содержит только названия функций, которые будут определены где-то в классе-потомке, без тел. Однако для удобства программиста языки программирования и требования к коду могут допускать в интерфейсах определённые виды данных и функций.

• Функции-утилиты. Пример: для абстрактного потока данных функция writeIntelWord(unsigned short) переводит число в порядок байтов «младший первым», а затем пишет два байта, вызвав интерфейсную функцию write.
• Эталонные реализации, в целом рабочие, но непригодные или неоптимальные для определённых потомков. Пример: для абстрактного потока данных функция remainder() возвращает size() - pos(). Она работает, например, для дискового файла или буфера памяти и отлично документирует, что должна делать. Но существуют потоки, которые не имеют длины, но имеют остаток (например, забуферизированный ввод из порта).
• В языке Си++ интерфейсу, как и любому виртуальному классу, поощряется иметь пустой виртуальный деструктор.
• Статические (общие для всех экземпляров) данные, особенно неизменяемые.

В любом случае интерфейс не может содержать:

• любые нестатические данные, кроме технических (указатель на таблицу виртуальных методов и т. д.);
• конструктор сверх того, чтобы эти технические данные инициализировать;
• незаконченные функции, неспособные работать «как написано» ни в одном потомке и требующие доработки;
• приватные функции, к которым потомки обращаться не могут.

Интерфейсы и абстрактные классы

Можно заметить, что интерфейс, с формальной точки зрения, — это просто чистый абстрактный класс, то есть класс, в котором не определено ничего, кроме абстрактных методов. Если язык программирования поддерживает множественное наследование и абстрактные методы (как например C++), то необходимости во введении в синтаксис языка отдельного понятия «интерфейс» не возникает. Данные сущности описываются с помощью абстрактных классов и наследуются классами для реализации абстрактных методов.

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

На уровне исполнения классическая схема множественного наследования вызывает дополнительный ряд неудобств:

• если объект может параллельно наследовать ${\displaystyle n}$ классов, существует ${\displaystyle n}$ независимых способов к нему обращаться, а значит должно существовать ${\displaystyle n-1}$ дополнительных указателей на него. С точки зрения автоматического управления памятью это будет означать, что возникают ссылки, указывающие в середину объекта;
• поддержка виртуальных вызовов подразумевает, что в объекте хранится ссылка на его виртуальную таблицу. В случае множественного наследования ${\displaystyle n}$ ссылок их активное использовании сильно увеличит объём памяти, занимаемой каждым экземпляром.

Использование схемы с интерфейсами (вместо множественного наследования) позволяет решить эти проблемы, если не считать вопроса о вызове интерфейсных методов (то есть виртуальных вызовов методов при множественном наследовании, см. выше). Классическое решение состоит в том (например, в JVM для Java или CLR для C#), что интерфейсные методы вызываются менее эффективным способом, без помощи виртуальной таблицы: при каждом вызове сначала определяется конкретный класс объекта, а затем в нём ищется нужный метод (разумеется, с многочисленными оптимизациями).

Множественное наследование и реализация интерфейсов

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

Тем не менее, одна коллизия при множественном наследовании интерфейсов и при реализации нескольких интерфейсов одним классом всё-таки возможна. Она возникает, когда в двух или более интерфейсах, наследуемых новым интерфейсом или реализуемых классом, имеются методы с одинаковыми сигнатурами. Разработчики языков программирования вынуждены выбирать для таких случаев те или иные способы разрешения противоречий. Вариантов здесь несколько:

• Запрет. В одном классе просто запрещается реализовывать несколько интерфейсов, имеющих методы с одинаковыми сигнатурами. Если для какого-то класса требуется комбинация несовместимых интерфейсов, программист должен выбрать другой путь решения проблемы, например, выделить несколько классов, каждый из которых реализует один из необходимых интерфейсов, и использовать их экземпляры совместно.
• Явное разрешение неоднозначности. В случае обнаружения компилятором коллизии от программиста требуется явно указать, метод какого из интерфейсов он реализует и вызывает. То есть одноимённые методы реализуются раздельно, а при вызове указывается, какой из них вызывается. При вызове одноимённых методов через переменную типа «интерфейс» неоднозначности не возникает, если использованный в качестве типа переменной интерфейс имеет только один метод с заданным именем. Вариантом этого решения является явное переименование для совпадающих по именам наследуемых или реализуемых методов, за счёт чего в пределах реализующего класса не будет одноимённых методов, но при обращении через интерфейс всегда вызывается нужная реализация.
• Общая реализация одноимённых методов. Если наследуется или реализуется несколько методов с одной и той же сигнатурой, то они объединяются в интерфейсе-наследнике, а в классе-реализаторе получают одну общую реализацию. Это хорошо подходит для случаев, когда одноимённые методы разных интерфейсов идентичны по предполагаемой функциональности, но может вызвать нежелательные эффекты, если поведение этих методов должно различаться.

Интерфейсы в конкретных языках и системах

Реализация интерфейсов во многом определяется исходными возможностями языка и целью, с которой интерфейсы введены в него. Очень показательны особенности использования интерфейсов в языках Java, Object Pascal системы Delphi и C++, поскольку они демонстрируют три принципиально разные ситуации: изначальная ориентация языка на использование концепции интерфейсов, их применение для совместимости, а также их эмуляция классами.

• В Java интерфейсы изначально входят в язык, являясь неотъемлемой его частью.
• В объектной подсистеме языка Object Pascal никаких интерфейсов не было, их поддержка была введена в Delphi 2 для обеспечения написания и использования COM-компонентов. Соответственно, механизм интерфейсов Delphi ориентирован, на использование технологии COM.
• В C++ интерфейсов, строго говоря, нет вообще. Механизм, аналогичный интерфейсам (и исторически предшествующий им) реализуется другими средствами чрезвычайно мощной объектной подсистемы этого языка.

IMyInterface = interface
  procedure DoSomething;
end;

TMyClass = class(TMyParentClass, IMyInterface)
  procedure DoSomething;
  function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
  function _AddRef: Integer; stdcall;
  function _Release: Integer; stdcall;
end;

implementation

TMyClass = class(TInterfacedObject, IMyInterface)
  procedure DoSomething;
end;

TMyClass = class(TObject, IInterface, IMyInterface)
  //IInterface
  function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
  function _AddRef: Integer; stdcall;
  function _Release: Integer; stdcall;
  //IMyInterface
  procedure DoSomething;
end;
{ TMyClass }

function TMyClass.QueryInterface(const IID: TGUID; out Obj): HResult;
begin
  if GetInterface(IID, Obj) then
    Result := 0
  else
    Result := E_NOINTERFACE;
end;

function TMyClass._AddRef: Integer;
begin
  Result := -1;
end;

function TMyClass._Release: Integer;
begin
  Result := -1;
end;

procedure TMyClass.DoSomething;
begin
  //Do something
end;

/**
*   interface.Openable.h
*
*/
#ifndef INTERFACE_OPENABLE_HPP
#define INTERFACE_OPENABLE_HPP
// Класс интерфейса iOpenable. Определяет возможность открытия/закрытия чего-либо.
class iOpenable
{
    public:
    virtual ~iOpenable(){}

    virtual void open()=0;
    virtual void close()=0;
};
#endif

/**
*   class.Door.h
*
*/
#include "interface.Openable.h"
#include <iostream>

class Door: public iOpenable
{
    public:
    Door(){std::cout << "Door object created" << std::endl;}
    virtual ~Door(){}

    //Конкретизация методов интерфейса iOpenable для класса Door
    void open() override {std::cout << "Door opened" << std::endl;}
    void close() override {std::cout << "Door closed" << std::endl;}

    //Специфические для класса Door свойства и методы
    std::string mMaterial;
    std::string mColor;
    //...
};

/**
*   class.Book.h
*
*/
#include "interface.Openable.h"
#include <iostream>

class Book: public iOpenable
{
    public:
    Book(){std::cout << "Book object created" << std::endl;}
    virtual ~Book(){}

    //Конкретизация методов интерфейса iOpenable для класса Book
    void open() override {std::cout << "Book opened" << std::endl;}
    void close() override {std::cout << "Book closed" << std::endl;}

    //Специфические для класса Book свойства и методы
    std::string mTitle;
    std::string mAuthor;
    //...
};

/**
*   test.Openable.cpp
*
*/
#include "interface.Openable.h"
#include "class.Door.h"
#include "class.Book.h"

//Функция открытия/закрытия любых разнородных объектов, в которых реализован интерфейс iOpenable
void openAndCloseSomething(iOpenable& smth)
{
    smth.open();
    smth.close();
}

int main()
{
    Door myDoor;
    Book myBook;

    openAndCloseSomething(myDoor);
    openAndCloseSomething(myBook);
    system ("pause");
    return 0;
}

public interface Drawable extends Colorable, Resizable {
}

public interface Directions {
  int RIGHT=1;
  int LEFT=2;
  int UP=3;
  int DOWN=4;
}

public interface Moveable {
  void moveRight();
  void moveLeft();
  void moveUp();
  void moveDown();
}

interface I
{
   void interfaceMethod();
}

public class ImplementingInterface implements I
{
   void interfaceMethod()
   {
      System.out.println("Этот метод реализован из интерфейса I");
   }
}

public static void main(String[] args)
{
   ImplementingInterface temp = new ImplementingInterface();
   temp.interfaceMethod();
}

interface A {
  int getValue();
}

interface B {
  double getValue();
}

interface C {
  int getValue();
}

public class Correct implements A, C // класс правильно наследует методы с одинаковой сигнатурой
{
   int getValue()
   {
      return 5;
   }
}

class Wrong implements A, B // класс вызывает ошибку при компиляции
{
   int getValue()
   {
      return 5;
   }

   double getValue()
   {
      return 5.5;
   }
}

interface I1 
{
    void Method1();
}
interface I2 
{
    void Method2();
}

interface I : I1, I2
{
    void Method();
    int Count { get; }
    event EventHandler SomeEvent;
    string this[int index] { get; set; }
}

public class C : I
{
    public void Method()
    {
    }

    public int Count
    {
        get { throw new NotImplementedException(); }
    }

    public event EventHandler SomeEvent;

    public string this[int index]
    {
        get
        {
            throw new NotImplementedException();
        }
        set
        {
            throw new NotImplementedException();
        }
    }

    public void Method1()
    {
    }

    public void Method2()
    {
    }
}

Интерфейсы в UML

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

В UML интерфейсы изображаются как классы со стереотипом «interface», либо в виде кружочков (в этом случае содержащиеся в интерфейсе UML-операции не отображаются).

См. также

• Microsoft Component Object Model Interface
• Компонентно-ориентированное программирование
• Интерфейс программирования приложений
• Абстрактный класс

Примечания

Ссылки

• Implement multiple interfaces

У этой статьи есть 3 проблемы, помогите их исправить:

Эту статью необходимо исправить в соответствии с правилами Википедии об оформлении статей.

Пожалуйста, помогите улучшить эту статью. (22 мая 2006)

В статье не хватает ссылок на источники (см. рекомендации по поиску).

Информация должна быть проверяема, иначе она может быть удалена. Вы можете отредактировать статью, добавив ссылки на авторитетные источники в виде сносок. (23 декабря 2009)

В статье есть список источников, но не хватает сносок.

Без сносок сложно определить, из какого источника взято каждое отдельное утверждение. Вы можете улучшить статью, проставив сноски на источники, подтверждающие информацию. Сведения без сносок могут быть удалены. (23 декабря 2009)

Пожалуйста, после исправления проблемы удалите соответствующий шаблон. Узнать, как это сделать, можно на справочной странице.