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

К примеру, какой-нибудь метод класса/интерфейса C имеет сигнатуру:

doSomething(A $a) {}

то есть он ожидает, что аргументом будет значение типа A. Если ты удалишь инструкцию implements A, то объекты класса B уже не будут относиться к этому типу, а следовательно ты не сможешь передать их аргументом в тот метод. Также, проверки вроде $b instanceof A будут выдавать false. Ну и т.п.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

А ещё код может использовать методы, описанные в интерфейсе без опаски встретить undefined method. Это когда пишете различные адаптеры с единым обработчиком.

Invis1ble в данный пример не въехал) А почему B раньше подходил. Я же могу всегда передавать, то что мне нужно.
Я как бы в теории за 3 дня почитал. И много примеров увидел. И как бы даже понимаю. Но все равно не могу четко представить. И в проекте видел их реализацию. Единственное, что заметил это наверное выский уровнеь абстракции, когда можно будет легко заменить допустим тот же драйвер о котором пишет
Nikitian. Если к примеру у меня 100 методов реализуют подключение к базе используя драйвер мускула. То я могу заменить драйвер. создав еще один класс реализации для драйвера. Ну если ты понял, что я сказал)
Но пока все опять туманно)

Nikitian
Ну так впринципе я могу и не писать адаптеры с единым обработчиком. В чем плюс написать интерфейс с пустыми методами и знать, что реализовывать перед тем, чтобы просто срзау не писать классы реализации без интерфейса?
А может разработчик интерфейса все не учел. И я хоть и не встречу андефайнед, но нужно будет садиться все исправлять(и ему и мне). А так я ни у кого не спрашивая, просто добавил бы новый метод, который мне нужен и все.

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

class A {
  public function doSomething(B $b) {}
}

interface B {}

class C implements B {}

$a = new A;
$c = new C;

$a->doSomething($c);

запусти и проверь. Потом удали implements B и запусти.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Invis1ble, Да вот теперь более понятно. Я бы даже сказал увидел наконец-то преимущество на элементарном примере, а не толкьо абстрактно на теории или в больших кусках кода.
Спасибо.

Вот ты пишешь, что в курсе теории, а сам задаешь вопросы ("почему B раньше подходил. Я же могу всегда передавать, то что мне нужно."), ответы на которые есть везде ;)
Вот тебе более развернутый пример:

class A {
  public function getGreetings(B $b, $name) {
    return $b->getHello() . ', ' . $name . '!';
  }
}

interface B {
  public function getHello();
}

class C implements B {
  public function getHello() {
    return 'hello';
  }
}

$a = new A;
$c = new C;

echo $a->getGreetings($c, 'SoMeOnE');

В данном случае нам удалось избежать в A::getGreetings() "ручных" проверок, что объект типа C действительно имеет метод getHello().

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Почитайте паттерны проектирования.

А интерфейсы использую в тех случаях, кода нужно создавать классы с заданной функциональностью. Например, классы-драйверы конкретных БД для создания абстрактного слоя баз данных.
Абсолютно никто не мешает иметь под рукой бумажку, на которой написано какие методы должен реализовать класс, чтобы его можно было использовать как драйвер к БД. Но гораздо легче определить класс как реализацию конкретного класса-интерфейса. Тода, если один из методов класса-интерфейса не будет определен или определен неправильно, это будет ошибка, о которай php-интерпритатор любезно сообщит.

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