Интерфейсы объектов для блондинок

а для чего еще интерфейсы то использовать?

 

DarkElf
Я автор интерфейсов или как?
Жгешь. Однако.

Из всего топика, в котором я практически не отметился, ты выцепил меня

Черт возьми, что ты от меня ожидаешь? Какому интерфейсу я должен соответствовать?

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

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

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

 

классное, "интерфейсное" слово, да? ))

 

Elkaz
ага, не то, что я замудрил, хотя то же самое.

 

но, в этом случае плагин, хотя бы, не упадет с fatal error'ом..)

 

[vs]
А методы проверять зачем? Как раз для защиты от рук программиста

 

[vs]
Метод есть, а вот что конкретно он делает... =))

 

так...можете считать меня блондинкой, но я ничего не понял...экзампл в студию!

 

это только твои проблемы.

 

а рассказать то все таки что такое интерефейсы и для чего они на примере предоставляется возможным?

 

прочти тему.

 

сейчас обвинят в неумении абстрактно объяснять

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

А, может, пока не засоряй голову?

 

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

 

ну, открой мануал и посмотри
http://www.php.net/manual/en/language.o ... rfaces.php
в первом же абзаце

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

 

свойства не определяются в интерфейсе

 

я щас одну такую умную (а может кому-то покажется, что глупую) вещь скажу, тогда может станет ясно.
впервые столкнулся с интерфейсами, когда стал использовать COM/OLE. было это в дэлфи. так вот, интерфейс - это по сути способ множественного наследования, коего, к примеру в ОО модели дэлфи не было.

 

на самом деле некое подобие свойтв в интерфейсе в том же COM есть. их можно реализовать через функции)

 

это так называемые геттеры/сеттеры - а по сути несусветная глупость.

Если вся его логика заключается в присвоении/чтении закрытого свойства - он нахрен не нужен.
А ноги растут из "традиционных" ООП языков типа Java, где не было возможностей динамических языков зато было старание формализовать все и вся в рамках своей парадигмы.

Между тем, к примеру, в C# уже пришли к неявным get/set для свойств. В PHP мы можем это реализовать при помощи __get/__set

PHP:

1. <?php
2. public function __get($name) {
3.     $getter = 'get' . ucfirst($name);
4.     if (method_exists($this, $getter) {
5.         return $this->$getter();
6.     } elseif (array_key_exists($name, $this->props)) {
7.         return $this->props[$name];
8.     } else {
9.         throw new Exception('property not found');
10.     }
11. }
12.  

Буде мне где-то потребуется геттер, мне достаточно будет его определить и он автоматически начнет использоваться.

 

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

 

Если я правильно помню, то причина как раз в этом: