Интерфейсы

когда ты в коде хочешь дёрнуть некий метод некоего объекта, то ты ожидаешь, что это такой объект, как надо, что у объекта есть нужный метод и он кушает те параметры, которые ты в него собрался скормить.

удостовериться в этом можно например отказавшись принимать в работу что-то кроме экземпляров определённого класса, например MySomeClass. Тогда, чтобы ты сам или другие могли что-то поменять в логике местами по необходимости, но чтобы всё работало как раньше ты просто наследуешься от класса MySomeClass и будет работать.

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

 

нэзашто, дарагой

 

@kentkent7, почитай Мэтта Зандстру, будет детально понятно, для чего нужны в том числе интерфейсы

 

@Алекс8
но ведь можно отнаследоваться от базового автомобиля =)
зачем интерфейс?

 

Это не верно. Интерфейсы нужны там, где пользуют полиморфизм. Конечно, если всё на скучных статических классах, они ни к чему. Но если нормальное ООП, то абстрактные классы и интерфейсы - основа. Интерфейс - фактически, абстрактный класс, в котором не реализован ни один метод и нет полей. То что ты не используешь приёмы ООП, не значит, что они не нужны. Инверсию зависимости, к примеру. Или абстрактные фабрики.

Можно. Но абстрактный базовый автомобиль - это если есть что-то кроме абстрактных методов. Интерфейс - когда одни методы, и все абстрактные. Кстати, можно сделать интерфейс ТоЧтоЕздит, сделать в нём методы ехать, стоять и т.п., и после этого сделать автомобили, трамваи и прочие транспортные средства. Возможно, в каком-то контексте будет всё равно, что заставлять ехать/стоять, автомобиль или трамвай, и тогда можно рассчитывать просто на интерфейс. Ну ты как раз об этом и писал. К тому же, в PHP нельзя наследоваться от нескольких классов, но можно реализовать несколько интерфейсов (ты, конечно, это знаешь, но чтоб было для людей)

 

Упрощённый пример использования интерфейсов в текущем проекте. Мне надо оперировать сущностями с динамическим набором свойств, которые к тому же определяются пользователем. И эту всю фигню надо извлекать из базы данных, по разному сортировать и т.п. Но как бы это всё не было отсоритровано, отфильтровано и т.п., собственно код, отвечающий за извлечение из базы строк и расфасовки их по объектам не меняется. Поэтому я делаю так:

PHP:

1. interface StorageFilter {
2.     public function filter(Builder $query); // Builder - это Query Builder из Laravel
3. }
4.  
5. class EntityStorage {
6.      public function readEntities(StorageFilter $filter = null)
7.      {
8.           $query =\DB::table("entityTable"); // Создаёт построитель запроса по определённой таблице
9.           if ($filter) {
10.                $filter->filter($query);
11.           }
12.           $results = $query->get()->all();
13.           /* Логика преобразования всего полученного в объекты моих классов */
14.      }
15. }
16. $storage = new EntotyStorage;
17. $entities = $storage->readEntities(new PropertyValueFilters($_GET["filter"]));
18. $entities = $storage->readEntities(new CreatedBetween($date1, $date2));
19.  
20. // А тут паттерн "композит", собираем вместе сколько угодно разных условий
21. $entities = $storage->readEntities(new QueryModifiersCollector([
22.       new PropertyValueFilters($_GET["filter"]),
23.      new CreatedBetween($date1, $date2),
24.      new OwnerIs(\Auth::user())
25. ]);

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

 

Я же привёл пример, из реального проекта. К тому же, если у меня интерфейс, я могу отнаследоваться от любого класса, и одновременно реализовать интерфейс. Мне это напоминает ситуацию в детстве, когда я уже освоил Turbo Pascal, а мой знакомый только BASIC. И он увидел у меня строк 100 интерфейсной части модуля, и давай спрашивать: а эта строчка что делает? А эта? И был удивлён, что из 50 строк ни одна не делала реальной работы

 

Зависит от проекта. Много чего толку ноль, когда что-то мелкое делаешь. Многие вещи только замедляют и усложняют разработку если проект не дорос до них. Но, с определенного момента, проект это перерастает.

Сегодня ты сам себе хозяин. А завтра ты нанял помощника себе. И понеслась...

А так, можно и про ООП говорить, что оно никому не нужно. Потому что когда делаешь что-то мелконькое, ООП больше мешает, чем помогает. Будет у тебя либо куча статики, либо одноразовых классов, по одному объекту на каждый за вызов, не более.

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

Инструментария много. И у каждого своя применимость. Если ситуация, когда инструмент нужен не наступила, это не значит, что он не нужный в принципе никому никогда.

 

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

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

 

плеснул позитивом прям в ебало
что с тобой? День плохой?

 

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