Доброе время суток. Хочу полностью разобраться с интерфейсами в ООП. Сколько не гуглил и читал с примерами, постоянно ведется недопонимание в их юзанья, а точнее какая в них полезность. На данный момент у меня в голове сложилось четкое понимание о них как составление описывающих классов с правилами ( какой класс с какими методами по дефолту должны содержать ) ВСЕ так какая же изюменка от интерфейсов, кроме как "помогает сторонним кодерам ориентироваться в твоем говнокоде" ? --- Добавлено --- Спойлер: new PHP: <? interface PHP_inter { public function add(); } class PHP_one implements PHP_inter { public function __construct ( $a ) { $this -> val = $a; } public function add() { return $this -> val; } } class PHP_two { public function __construct (){} public function test( root $b ) { return $b -> add(); } } $one = new PHP_one( 44 ); $two = new PHP_two; echo $two -> test( $one ); # 44 с тем же замахом я могу тупо взять удалить интерфейс и в методе тест наименование. Тот же результат будет
я не понимаю, чего ты не понимаешь интерфейс удобный способ знать заранее, что есть методы. А какой класс - не важно. Это удобнее, чем наследоваться от отдного класса всегда. Иногда это не нужно. Достаточно наследоваться от некоей договорённости о методах. Вот и всё.
я кстати тоже такой же вывод сделал)) абстрактные, финальные классы - это для того что бы другим было удобно))
от одного --- Добавлено --- наследование через интерфейсы, а не через extends ? или не понял твое предложение
Для того, чтобы тебе было удобнее. Мало ли что нужно будет сделать с проектом через год. Вот к примеру, пришлось мне писать проект на Code Igniter, противный такой недофреймворк. Код, составляющий самую основу проекта, благодаря интерфейсам написан так, что я могу подменить часть работающую с БД, на работу через слой любого фреймворка, он там сосредоточен. Потом, я могу переписать код на работу с любой базой данных минимальными усилиями. Ну и потом, автоматическое тестирование - если класс зависит от интерфейса, а не от другого класса, то можно подменить реализацию на тестовую, гарантированно работающую но дебильно простую, чтоб не отвлекаться. Но это про интерфейсы. Абстрактные классы же могут содержать часть функционала, тут вообще другая история. Паттерн "шаблонный метод", к примеру, реализуется через абстрактный класс. Да и много чего. В принципе, сама суть ООП в абстрактных классах. Если код с классами не содержит полиморфизма, его можно запросто переписать на процедуры, он только упростится от этого. Если не нужен полиморфизм, т.е. нигде нету необходимости работать с экземпляром наследника так, как будто работаешь с экземпляром родителя, значит не нужно ООП. Без полиморфизма оно вообще ничего не даёт.
Интерфейс простейшая инструкция к классу какие методы использовать. Можно конечно и в абстрактном родителе их объявить, но тогда четко надо прописывать public к открытым методам и protected к общим методам классов библиотеки и потом смотреть где что. В случае с интерфейсом тупо скопировал методы без разбора и пиши свою реализацию. Плюс заглядываешь в родителя абстрактного, если есть он конечно, и уже решаешь нужны ли тебе общие методы и стоит ли от него наследоваться. Кому то удобно, кому то нет.
в том примере я бы с таким успехом выполнил бы со статическим методом, где используется интерфейс (UsersInterface $users) User::addUser меньше кода. и тут снова начинаю гнобить чертовы интерфейсы о их существований, так как альтернативу могу прописать
@MouseZver, единственное адекватное использование интерфейсов, которое мне приходилось применять - это проверка принадлежности экземпляров разных классов к одному интерфейсу. Как выше было сказано:
В PHP есть конструкции, вроде foreach и throw. И есть стандартные типы и классы, вроде array и Exception, которые можно использовать с этими конструкциям. Хочешь бросить исключение - используй только new Exception. Нет! Wrong way! throw - это часть языка. А класс - не должен быть частью языка. Не справедливо ограничивать применение языковых конструкций только лишь теми классами, которые написали авторы PHP-машины. Поэтому в PHP добавили интерфейс Throwable. В будущем можно будет "бросить" любой объект, имплементирующий этот интерфейс, и одновременно несколько других. А теперь поставь на место встроенных конструкций, собственные функции, работающие с объектами. Ты не должен заставлять программиста, который будет этим пользоваться, использовать твои классы. Дай ему интерфейсы, чтобы он мог использовать твои функции со своими объектами.
http://www.cyberforum.ru/php-oop/thread603078.html --- Добавлено --- Окончательно - Интерфейсы не нужны.