Интерфейсы

PHP:

1. if (!$engine instanceof Engine) {
2.     throw new Exception('some error...');
3. }

 

На самом деле, там может быть гораздо сложнее. непример, если $engine не входит в иерархию Engine, а берется из какого нить компонента. В общем, все не так тривиально, как кажется.

 

Sergey89
Против второго варианта ничего не имею, там все ок. А что касается этого -

PHP:

1. <?php
2. interface Vehicle {
3.     public function drive();
4. }
5.  
6. abstract class Car implements Vehicle {
7. }
8.  
9. class Nissan extends Car {
10.     public function drive() {/* */}
11. }

Здесь объявление класса Car, пусть и абстрактного, не соответствует интерфейсу. И если PHP позволяет такое - значит, бага, т.к. нарушаются принципы ООП.

 

я использую интерфейсы примерно так

PHP:

1.  
2. <?
3. interface temp {
4.    
5.      const $str1 = "first";
6.      const $str2 = "second";
7. }
8.  
9. class myClass1 implements temp{
10.  
11.   function print_str() {
12.      echo "this is ".self::str1." string in myClass1";
13.   }
14. }
15.  
16. class myClass2 implements temp{
17.  
18.   function print_str() {
19.      echo "this is ".self::str2." string in myClass2";
20.   }
21. }
22.  

вообще такое использование интерфейсов правильно?

 

Я пупею от нашего любимого PHP и его взглядов на ООП нет блин, неправильно!
Не должно быть в интерфейсах никаких констант. Это опять из оперы абстрактных классов.

 

А можно увидеть вариант как правильно?)
Мне просто надо в класс "подгрузить" некоторые общие, для нескольких классов, константные переменные. Как это сделать правильно? У меня маловато опыта еще в этих делах

 

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

 

Dagdamor

PHP:

1. <?php
2. interface Vehcile {
3.     // ...
4. }
5.  
6. interface Car extends Vehcile {
7.     // ...
8. }
9.  
10. class Nissan implements Car {
11. }

Тоже нарушение принципов ООП?

 

Я тебе всё намекаю, что разница между абстрактным классом и интерфейсом только в том, что абстрактный класс может содержать общую для разных классов реализацию методов.

 

дальше спор будет о том, что Wikipedia недостоверный источник информации

 

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

 

Ну например так. Представь что ты пишешь игру. В ней есть монстры. Наземные и летающие.

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

Но при этом львы и орлы - хищники, а канарейки и зебры нет. И вот появляется интерфейс "хищник", с методами "преследовать добычу", "убивать добычу" и "жрать_мясо". Причем они по разному преследуют, по-разному убивают и по-разному жрут мясо. Львы и орлы имплементируют этот интерфейс, а канарейки нет. При этом ты можешь объявить

Хищник орел1 = new Птица()
Хищник лев1 = new Зверь ()

после этого с орлами и львами можно обращаться и как с хищниками и как с зверями/птицами.

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

 

Sergey89

Если в интерфейсах есть декларация методов, а в классе Car ни фига нет - то безусловно!

 

karakh

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

 

karakh
самый нормальный ответ...
вообще не пойму дискусси, всё просто - класс может наследовать только одник абстрактный класс в парэнте, а интерфейсов он может наследовать НЕСКОЛЬКО - в этом вся суть МНОЖЕСТВЕННОЕ НАСЛЕДОВАНИЕ. Если ктото не предстваляет как это применить и где без этого не обойтись - то это его проблема, а те, кто в свое время всосал С и С++ вообще бы даже топик не смотрели...

 

Хе) Действительно. Странно, что ранее этого никто не упомянул.

 

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

 

Что есть "наследование классом интерфейса" я не знаю. Класс не наследует интерфейс а имплементирует (как бы это по-русски сказать?).

Если нужна миграция разных животных на юг, то можно сделать десяток Животное <тварь_1> = new Птица() /Зверь и вызвать каждому метод "лететь(юг)". И куча животных отправятся на юг, питаясь по пути кто чем умеет. Хищные, травоядные, насекомоядные - любые.

Если нужна толпа разных хищников (зверей и птиц, а заодно и троллей, не относящихся к классу Животные вообще) охотящихся на зайца, то создается Хищник <тварь_1> = new Птица()/Зверь() и вызвать каждому "преследовать(заяц)". И куча хищников - кто бегом, кто в полете - будут преследовать зайца.

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

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