Какова роль интерфейсов в ООП?

Question

[Матвей Мамонов]

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

Comments

[Матвей Мамонов]

Кстати, тот же вопрос и про абстрактные классы.

Answer 1

[Леша Киселев]

Приведу пример на коленке. Хотим, например, написать абстрактную файловую систему. Для начала, определим интерфейс, для ФС:

interface FileSystemInterface {
  public function write($file, $data);
  public function read($file);
}

Затем, хочу реализацию интерфейса ФС для работы с файликами:

class OSFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем файлик, пишем данные
  }

  public function read($file) {
    // открываем файлик, возвращаем данные
  }
}

Вдруг, кому-то захотелось файловую систему в облаке. Окей, не проблема, реализуем это:

class CloudFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем соединение с облаком, пишем данные
  }

  public function read($file) {
    // открываем соединение с облаком, возвращаем данные
  }
}

Пусть у нас есть кой-то код, работающий с файловой системой, назовем его "Хранилище файлов". Пусть он выглядит примерно так:

class FileStorage {
  protected $Fs;
  
  public function __construct(FileSystemInterface $Fs) {
    $this->Fs = $Fs;
  }  

  public function saveFile() {
    $this->Fs->write('file.txt', 'file data');
  }

  public function getFile() {
    return $this->Fs->read('file.txt', 'file data');
  }
}

Отлично! Теперь мы можем хранилищу файлов отдать любой объект с реализованным интерфейсом FileSystemInterface. Пример:

// Хранилище файлов работает с файловой системой ОС:
$FS = new OSFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

// Хранилище файлов работает с файловой системой в облаке:
$FS = new CloudFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

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

Comments

[Валерий Рябошапко]

Круто, спасибо! :-)

[Матвей Мамонов]

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

[Леша Киселев]

Матвей Мамонов:
>> "Но ведь это можно контролировать и самому?"
Конечно, дело твое как писать свой код :)

>> "Тем более, если мне, например, для облака некоторые функции не нужны будут?"
Значит, система спроектирована не верно. Потребуется разбивать интерес на несколько. Или полностью его переделывать.
Как вариант, конечно, в методах которые не нужны, кидать исключение, что бы их не использовали.
Как-то так:

interface FileSystemInterface {
    public function write($file, $data);
    public function read($file);
    public function setFileAccess($file, $access);
}

class CloudFileSystem implements FileSystemInterface {
    public function write($file, $data) {
        // открываем соединение с облаком, пишем данные
    }

    public function read($file) {
        // открываем соединение с облаком, возвращаем данные
    }

    public function setFileAccess($file, $access) {
        throw new LogicException("Method not allowed at CloudFileSystem");
    }
}

[Матвей Мамонов]

Леша Киселев: по вашим примерам эти интерфейсы только ненужной работенки прибавляют.

Не столь оправданы затраты временные на слежение за всеми интерфейсами, сколько будет мороки с их правкой.

[Матвей Мамонов]

Леша Киселев: видимо, использовать их логично в таких примерах, типа ваших, когда 2 класса почти идентичны друг другу, но направлены на разные области.

Кстати, что касается "Конечно, дело твое как писать свой код :)":
Зачем порождать быдлокод? Я за строгость. Пусть все пишут в одном стиле (утопия, согласен), зато все будут понимать друг друга.

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

[Леша Киселев]

Матвей Мамонов:
>> "по вашим примерам эти интерфейсы только ненужной работенки прибавляют."
И где же?

>> "Не столь оправданы затраты временные на слежение за всеми интерфейсами, сколько будет мороки с их правкой."
Что значит "следить за всеми интерфейсами"?

Почитать бы https://refactoring.guru/ru/catalog для "просветления".

[Матвей Мамонов]

Леша Киселев: "и где же?"
Вася создал интерфейс (Вася тимлид, Вася точно знает, какие функции должен реализовывать класс).
Миша пишет класс. Миша решил, что метод MyMethod совсем не нужен. Миша тестит и получает фатальную ошибку. Итог: Мише надо сообщать Васе, что интерфейс содержит лишнее, а Васе надо лишнее удалять. Очевидно же.

Обязательно почитаю, спасибо :)

[Леша Киселев]

Матвей Мамонов: Странная логика получается. Не нужно писать интерфейс, ради интерфейса. Оно не так работает.
И пример слишком абстрактный, что бы его обсуждать. Давайте конкретику.

[tasce]

Создавая интерфейс, вы тем самым можете быть спокойным за наличие в классе методов, которые наследуются от интерфейса. Сейчас вам может показаться это излишним, но вам просто нужно лучше изучать и углубляться в ООП. Интерфейсы описывают протокол взаимодействия и содержат только нужные методы, а уже потом их классы сами расширяют. "Миша решил, что метод MyMethod совсем не нужен. " Миша ничего не решает: он либо обязан унаследовать интерфейс и реализовать все методы, либо он пишет говнокод.

[Матвей Мамонов]

tasce: Очень грубо говоря, Миша решает все, ибо он код и пишет.
Но речь не об этом.

[Матвей Мамонов]

Леша Киселев: вопросов нет, прошу.

(Мне важно только, правильно ли я все понял)
* - рассуждения.
ТЗ: написать класс, регистрирующий пользователя.

* - Что должен делать класс? - Регистрировать. - Значит, обязательный метод должен быть один: Register. - Что-нибудь еще? - Пароль обязательно должен быть зашифрован. Значит, еще один обязательный метод: Hashpassword.

* От этого и пляшем.

interface iRegistration {
public function Register;
private function Hashpassword;
}

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

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

[tasce]

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

[Матвей Мамонов]

Леша Киселев: и тогда еще вопрос. Если я подключаю классы spl_autoload_register()'ом, то как лучше подключать интерфейсы, ведь не будешь же их для каждого класса создавать?

[Леша Киселев]

Матвей Мамонов: воспользуйтесь composer'ом, у него отличный автолоадер классов. https://getcomposer.org/
И следуйте стандарту PSR-*
PSR-0: www.php-fig.org/psr/psr-0/ru

Answer 2

[Станислав Макаров]

Много ответов есть уже, лучше попробую идти рядом с вашими словами. Итак,
> Зачем мне создавать файл, контролирующий это, если я и сам могу контролировать то, какие методы у меня есть
Вы - это ваша голова, вы человек, не робот, ваш может не быть на работе например, или вы сами можете забыть, как у вас взаимодействуют части системы. Интерфейсы - это в общем-то тоже документация. И не нужно строго различать "чисто интерфейсы", и интерфейсы класса - те методы, которые у класса паблик - это точно такой же интерфейс, только он явно не отделен от класса. Когда у класса всего 3-4 метода, и все они связаны простой идеей, то и выделять ничего не надо. Когда у класса уже 10 методов, и среди них есть небольшие смысловые группы, то уже имеет смысл эти группы подчеркнуть. И, в конце концов, вместо каши из 10 методов, вы читаете следующее: class Graph : IEnumerable, IIndexable, IDrawable - и вы знаете, что ваш граф перечисляется, индексируется и рисуется. Это уже очень много информации, вы уже понимаете, как взаимодействуют части вашей системы.

> Может создано это для работы в больших коллективах? Но ведь тогда любой участник сможет поправить и интерфейс.
Да, совершенно верно, для больших коллективов. Нет, участник просто так не сможет поправить интерфейс, не побеседовав с остальными. В лучшем случае участнику придется поправить весь код, который "висит" на этом интерфейсе, в худшем - он в принципе ничего не сможет поменять, если интерфейс "публичный" и используется несколькими командами разработчиков. Классический пример - системы плагинов. Если к MS Word-у уже написано куча плагинов, то MS не может взять и просто так поменять ифейсы, не поломав совместимость. Хотя некоторые аспекты реализации - может. Потому что, как уже сказали выше, интерфейс - это ДОГОВОР. Чем БОЛЕЕ он стабилен, тем ЛУЧШЕ. Команды договариваются (!), создавая интерфейсы, чтобы потом было как можно МЕНЬШЕ конфликтов и разногласий, т.к. проблемы с интерфейсом затрагивают всех. Найдите любую команду от 30 человек, и вы увидите, насколько это все важно.

Еще две вещи напоследок:
1) интерфейсы из ОО языков лишь частный пример понятие интерфейса в жизни вообще. Вы же, когда покупаете SATA-диск, наверное рассчитываете, что сможете его подключить к своему компу? А с чего вы взяли? А, ну конечно, ведь на упаковке написано SATA - значит производитель соблюдает ДОГОВОР - интерфейс передачи данных;
2) необходимость в некоторых фичах языков сложно осознать в личных проектах и даже в маленьких командах. Это тоже как в жизни: свой дом, как говорится, должен построить каждый мужик, а чтобы построить бизнес-центр или высотку, нужны определенные знания, т.к. другие масштабы. Это нормально. Тем не менее, нужно читать и искать примеры. Хотя современные ОО-языки и сами дают много примеров. Раз у вас PHP, почитайте про Iterator например.

Comments

[Матвей Мамонов]

Исчерпывающе. Спасибо.

Answer 3

[Антон Зеленский]

Дело нехитрое. Нужда в интерфейсах возникает, когда над кодом начинает работать более 1 человека. Себя, Матвей, вы контролировать можете, коллегу – уже в меньшей степени.
Еще печальней дела обстоят, когда вы выпускаете код, который может быть расширен неизвестно кем, неизвестно с какой целью (фреймворки). Очевидно, вам захочется сообщить будущим пользователям вашего кода, как конкретно этим кодом следуе пользоваться. Именно эту задачу решают интерфейсы.

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

Answer 4

[iliyaisd]

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

IPayer payer = this.getPayer((String) payments.get(i).getSystemCode());
payer.processPayment(payments.get(i));

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

Answer 5

[Владимир Мартьянов]

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

Answer 6

[Сергей]

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

Абстрактные методы в абстрактном классе играют ту же роль, что и интерфейс - описывают набор обязательных методов. Но при этом в абстрактном классе можно реализовать некоторые методы, которые в скорее всего будут одинаковы для многих потомков (хотя бы для 2х). Таким образом избегаем копипаста в коде

Comments

[Матвей Мамонов]

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

А если этот самый Вася сам и написал интерфейс?
Или если интерфес написал человек, который и понятия не имеет, что может понадобиться какой-то еще обязательный метод? Который потом упустили (для примера) из за отсутствия в интерфейсе.

[Виталий Хоменко]

Матвей Мамонов: Как правило человек, который создает интерфейс, создает и архитектуру приложения\компонента. Он знает, какие задачи должно решать приложение\компонент, как оно должно работать, планирует его и создает. Если все сделано хорошо, то проблем не будет. Но бывает, что допускают ошибки. Все мы люди...

[Матвей Мамонов]

"Он знает, какие задачи должно решать приложение\компонент"
Когда вы едете покупать новый ковер, вы точно уверены, какой узор на нем будет?

Вот и я, когда создаю новый класс, точно не могу сказать, какие методы он будет реализовывать.

[Леша Киселев]

>> "Когда вы едете покупать новый ковер, вы точно уверены, какой узор на нем будет?"

Но я точно знаю, что я еду покупать ковер. Это и есть интерфейс, он определяет общие детали. Все остальное на реализации конкретных классов.

[Матвей Мамонов]

Леша Киселев: ладно, убедили. Тогда, получается, что интерфейс должен содержать объявления САМЫХ глобальных методов, без которых класс не имеет смысла?

Например, класс Registration обязательно должен содержать функцию Register, но необязательно - PasswordHashing (вообще, конечно, обязательно, но я для примера). Значит в интерфейсе этого класса обязательно должна быть только функция Register?

[Леша Киселев]

Матвей Мамонов:
"ладно, убедили. Тогда, получается, что интерфейс должен содержать объявления САМЫХ глобальных методов, без которых класс не имеет смысла?"
Похоже на правду.

[Леша Киселев]

Матвей Мамонов:
>> "Например, класс Registration обязательно должен содержать функцию Register, но необязательно - PasswordHashing (вообще, конечно, обязательно, но я для примера). Значит в интерфейсе этого класса обязательно должна быть только функция Register?"

В зависимости от того, каких целей требуется достичь.

Answer 7

[F1NaL]

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

Comments

[Леша Киселев]

Ага, значит, если я работаю один с кодом, то интерфейсы мне не нужны?

[Матвей Мамонов]

Леша Киселев: логично.

[Матвей Мамонов]

А, то есть, прежде чем один разработчик начнет писать свой класс, он должен чекнуть интерфейс? И вообще, откуда он узнает, какой именно интерфейс ему смотреть? Да и откуда он вообще узнает, что интерфейс для этого класса есть?

[Леша Киселев]

Матвей Мамонов: это был сарказм, если что.

[F1NaL]

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

[Матвей Мамонов]

Леша Киселев: я понял сарказм, но сарказм получился слишком реальным.

[Станислав Макаров]

@eucalipt
> Да и откуда он вообще узнает, что интерфейс для этого класса есть?
Если он пользуется конкретным языком и фреймворком - то очень полезно знать сущестующие договоренности в языке (например, IEnumerable в C#. Кто не знает что есть такой ифейс, не считается знающим язык) и фреймворке. Если работает с другими в коллективе - коллектив садится, решает и документирует, какие интерфейсы нужны, где будут лежать файлы с кодом определений этих ифейсов, и какие есть доп. договоренности, которые кодом не опишешь.

[Матвей Мамонов]

Станислав Макаров: теперь понятно.

Answer 8

[trevoga_su]

> Но ведь тогда любой участник сможет поправить и интерфейс.

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