Как происходит выбор реализации интерфейса?

Question

[vasx3]

Подскажите, как происходит выбор реализации интерфейса когда один интерфейс реализуют несколько классов?

Допустим, у нас есть интерфейс машины

interface ICar {
  start();
  stop();
}

Его реализуют несколько классов

class Sportcar implements ICar {
  start() {
     /**/
  }
  stop() {
    /**/
  }
  //nitro() {
  //  /**/
  //}
}
class Bus implements ICar {
  start() {
     /**/
  }
  stop() {
    /**/
  }
  //openDoor() {
  //  /**/
  //}
}

В конечном методе можно получить объект по типу интерфейса и оно будет работать

function startCar(ICar $car) {
  $car->start();

Но как происходит выбор класса который, в конечном итоге, возвращается в методе?
(неактуально)Как можно быть уверенным, что мне вернётся объект класса Bus, и что в нём будет метод openDoor?

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

upd.
Грубо говоря, мне непонятно, в каком случае при использовании переменной ICar $car будет получен объект Sportcar, а в каком объект Bus?
Или лучше сразу получать переменную типа Sportcar или Bus, а интерфейс использовать только для стандартизации?

Comments

[res2001]

Как можно быть уверенным, что мне вернётся объект класса Bus, и что в нём будет метод openDoor?

Никак. В вашем интерфейсе нет метода openDoor. Функция оперирующая интерфейсом имеет доступ только к методам объявленным в интерфейсе. Если нужно использовать openDoor, то вы должны принимать в параметре Bus, а не ICar.

Но как происходит выбор класса который, в конечном итоге, возвращается в методе?

О выборе правильно метода заботится ЯП, так что вы просто пользуйтесь.
Если хочется деталей, то надо опускаться на уровень конкретного ЯП и смотреть как в нем реализовано наследование и виртуальные методы. В С++, например, это делается с помощью указателя на таблицу виртуальных методов - у предка она своя, у наследника своя, выбор нужного метода происходит "автоматически".

[vasx3]

res2001, хорошо, пусть будет PHP или C# как в их случае происходит выбор правильной реализации? Эта дырка в знаниях сильно мешает понять ООП.

[res2001]

vasx3, Эта дырка в знаниях никак не мешает понять ООП. Просто примите, что это так работает и идите дальше. Мне в свое время ни капли не мешало, что при изучении С++ я не знал как под капотом устроено наследование и виртуализация. Потом что-то сам додумал, что-то прочитал, хотя особой надобности в этих знаниях у меня нет и нигде это знание не пригодилось.

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

[vasx3]

res2001, заманчивая мысль, но с одной стороны не понятно, как правильно пользоваться интерфейсами, а с другой появляется "магия"

[res2001]

vasx3, А к примеру cout << "Hello world" в С++ не магия? Подберите аналоги из ваших ЯПов.

[vasx3]

res2001, дополнил вопрос (что по сути, я пытаюсь понять)

[res2001]

vasx3,

не понятно, как правильно пользоваться интерфейсами

Почему, собственно?
Из вашего примера: startCar принимает ICar, почему же вы считает, что вы в starCar можете вызвать openDoor? Этого метода нет в ICar. В starCar доступно только то, что описано в ICar.

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

Правильно говорится. Делается это для минимизации зависимостей. Ваш startCar будет зависеть только от интерфейса, вы можете в дальнейшем еще 10 специализаций интерфейса сделать, а startCar останется неизменным.

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

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

[vasx3]

Из вашего примера: startCar принимает ICar, почему же вы считает, что вы в starCar можете вызвать openDoor? Этого метода нет в ICar. В starCar доступно только то, что описано в ICar.

Это я понял, спасибо, просто не стал править вопрос в этих местах.

Я имел ввиду, что мне непонятно, в каком случае при использовании переменной ICar $car будет получен объект Sportcar, а в каком объект Bus?

[res2001]

vasx3, При вызове функции Sportcar вы должны будете пердать ей параметр. Передадите Sportcar - будет получен Sportcar в виде ICarа, а передадите Bus - будет получен Bus в виде того же ICara. Все очень просто :)

[vasx3]

res2001, да, теперь понимаю) В основном это непонимание возникло из-за dependency injection, при котором не нужно передавать объект в параметрах, оно часто используется в Symfony, но это уже буду отдельно изучать.

[res2001]

vasx3,

из-за dependency injection, при котором не нужно передавать объект в параметрах

Бред.
Я не знаю что там у вас в симфони, но вы в любом случае должны передать объект, иначе функция не будет знать с чем она работает (синтаксическая ошибка проще говоря - вы не можете вызвать функцию имеющую параметр без параметра). Подозреваю, что в симфони вы просто явно не вызываете эти методы, вместо этого симфони сама это делает за вас и она сама внутри себя передает туда нужные объекты. Но это ничего не меняет.

Answer 1

[Григорий]

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

Comments

[vasx3]

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

[Григорий]

Есть разные ситуации. Интерфейс должен использоваться там где коркретная реализция для исполнителя неважна. То есть после после создания объекта и складывания его в контейнер "интерфейсов" уже не важно что там за объект и использование его "личных" методов не подразумевается(хотя и не запрещается(но нужно знать как)).

[vasx3]

Григорий, ну, тут уже скорее место для абстрактных классов.

[Григорий]

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

Answer 2

[soloveid]

Среда выполнения знает какая именно реализация (Bus или Sportcar) стоит за ICar и именно методы
этого класса и вызывает.
Это происходит так потому, что в начале памяти, где находится этот объект, указан его тип (Bus или Sportcar).

upd.
Грубо говоря, мне непонятно, в каком случае при использовании переменной ICar $car будет получен объект Sportcar, а в каком объект Bus?
Или лучше сразу получать переменную типа Sportcar или Bus, а интерфейс использовать только для стандартизации?

Не совсем понятно, зачем Вам это знать? Для этого и есть интерфейсы. Если Вы вдруг хотите значить, какой именно тип и в этом случае выполнить какой-то отдельный код, то это нехорошо.