Алексей Алюшенко: если ваша задача - не нагружать сервер, то нужно скрипт не пилить, а оптимизировать. Если вы должны кому-то $100, неважно ведь будете вы их отдавать долларовыми бумажками или одной - результат один.
Забудьте на секунду про this. Bind и call делают разные вещи - bind привязывает контекст для последующего вызова, а call сразу вызывает функцию с указанным контекстом.
Результат совершенно разный. Попробуйте поэкспериментировать с этим вариантом, там понятнее различия - https://jsfiddle.net/koceg/p2utcp9j/1/
Потому что bind вернёт ссылку на функцию, а call - результат её выполнения. То есть callback будет выполнен в момент установки свойства, а после резолва промиса вывалится ошибка, что undefined (то, что сейчас возвращает callback) не является функцией.
Но это уже к вопросу не относится напрямую - можно просто cb привязать к промису, если контекст не нужен (хотя, обычно его сохраняют, конечно).
Sergey Goryachev: я понимаю о чём вопрос. Но 1) логи и настройки - это не обычные текстовые файлы и 2) как я уже сказал, в мире линуксовых серверов понятие "обычный текстовый файл" в общем-то отсутствует.
hubramubr: > Но в любом случае он должен разбираться хотя бы немного. Иначе его команда будет не эффективна.
Это менеджер будет неэффективен, а не команда. Но, честно говоря, я не вижу чем хороший менеджер проекта на java отличается от хорошего менеджера проекта на php.
safenoob: смысл от этого не меняется. Ваш метод getTickets возвращает массив строк, а вы потом на каждой строке пытаетесь вызвать метод getTitle, которого там нет и быть не может.
ubernoob: именно на практике и понять :)
Если говорить просто, пока вы не столкнётесь с ситуациями, когда нужен интерфейс, сложно начать их использовать. Тут люди ударяются в две крайности: или пишут на каждый чих по интерфейсу, или вообще их не создают.
Если говорить в контексте php, например, интерфейсы нужны, чтобы ваш код "упал" как можно быстрее, если что-то пойдёт не так и упростить методы, убрав из них проверки типов. Самое раннее, когда вы заметите ошибку - это если вы объявляете, что класс реализует интерфейс, но создаёте не все необходимые методы. Тут вам и IDE подскажет и код сразу при запуске умрёт с ошибкой. Если этого не произошло, дальше скрипт автоматически завершится, если вы в метод, ожидающий объект, реализующий какой-то интерфейс, передаёте что-то другое. Таким образом проще отлавливать баги.
Можете начать вот с такого правила: тайп-хинтите в методы конкретные классы. Если встречаетесь с ситуацией, когда метод может принимать объекты нескольких схожих классов, выделяете общее API в интерфейс или абстрактный класс и тайп-хинтите уже его. Как видите, размер проекта или команды тут совсем ни при чём.
Что конкретно в приведённом примере вам непонятно? Он же простой очень. Что значит "не дал результатов", что не получилось, какие ошибки и т.п.?
В текущей формулировке на ваш вопрос невозможно дать ответ.
Алексей Тен: это не IIFE.
Я согласен, что в моём ответе не раскрыты все подводные камни такого кода и нет описания принципов его работы (хоть он и решает конкретно ту задачу, которая озвучена в вопросе).
Но и ваши комментарии не особо конструктивны - вместо того, чтобы пытаться меня подловить, вы могли бы дополнить ответ, чтобы он перестал быть "плохим".
Я бы не назвал второй вариант костылём. Да, он не так удобен, но это стандартный метод и он работает. При это вся остальная ваша логика не сломается, ведь ваши объекты по прежнему будут реализовывать все нужные интерфейсы, просто в конкретных методах принадлежность объекта к ним будет проверяться не автоматически на этапе вызова, а руками при исполнении кода.
Что касается остального вашего комментария: я не предлагаю отказаться от ваших интерфейсов, пусть они будут. Но выделите то, что используется в повторяющихся методах в отдельный новый интерфейс. Если вы сделаете не getCoverDownloadPath/getOgCoverDownloadPath, а getDownloadPath и т.п., уверен, общие методы можно будет выделить.
Если коротко, что я пытаюсь сказать: методу removeOldFiles не нужен весь интерфейс CoverInterface, ему нужна только часть этого интерфейса, которая отвечает за хранение обложки. И именно эту часть можно вынести в отдельный интерфейс и тайп-хинтить именно его.
В зависимости от конкретного кода, я вижу два решения:
1. Выделить-таки какие-то части, которые используются в общих методах, в отдельный интерфейс. Что там такого может быть в этих сущностях настолько разного в публичном апи, что для метода moveTmpFile нужно указывать прямо специальный интерфейс?
2. Не указывать интерфейс в сигнатуре метода, но оставить его в DocBlock, а в коде тип проверять руками.
В Yii вы ничего не отправляете и там нет form.serialize()...
Задайте конкретный вопрос с конкретным php-кодом.
А ещё лучше - попробуйте просто запустить этот код и разобраться самостоятельно, элементарные вещи же спрашиваете.
