Я бы не назвал второй вариант костылём. Да, он не так удобен, но это стандартный метод и он работает. При это вся остальная ваша логика не сломается, ведь ваши объекты по прежнему будут реализовывать все нужные интерфейсы, просто в конкретных методах принадлежность объекта к ним будет проверяться не автоматически на этапе вызова, а руками при исполнении кода.
Что касается остального вашего комментария: я не предлагаю отказаться от ваших интерфейсов, пусть они будут. Но выделите то, что используется в повторяющихся методах в отдельный новый интерфейс. Если вы сделаете не getCoverDownloadPath/getOgCoverDownloadPath, а getDownloadPath и т.п., уверен, общие методы можно будет выделить.
Если коротко, что я пытаюсь сказать: методу removeOldFiles не нужен весь интерфейс CoverInterface, ему нужна только часть этого интерфейса, которая отвечает за хранение обложки. И именно эту часть можно вынести в отдельный интерфейс и тайп-хинтить именно его.
В зависимости от конкретного кода, я вижу два решения:
1. Выделить-таки какие-то части, которые используются в общих методах, в отдельный интерфейс. Что там такого может быть в этих сущностях настолько разного в публичном апи, что для метода moveTmpFile нужно указывать прямо специальный интерфейс?
2. Не указывать интерфейс в сигнатуре метода, но оставить его в DocBlock, а в коде тип проверять руками.
В Yii вы ничего не отправляете и там нет form.serialize()...
Задайте конкретный вопрос с конкретным php-кодом.
А ещё лучше - попробуйте просто запустить этот код и разобраться самостоятельно, элементарные вещи же спрашиваете.
Как я уже сказал, задайте про бэкенд отдельный вопрос. Но да, это стандартные get-параметры и они будут стандартно обработаны сервером. А в $_GET['foo'] будет содержаться массив из двух элементов.
Вообще, интересно на досуге покопаться действительно ли это так. Вставка в DOM или просчёт лэйаута я понимаю, дорогие операции - но поиск элемента-то не должен быть сильно дорогим, кмк.
