AM
Вроде того
Size: a a a
2020 August 13
СП
Понял, спасибо :)
DS
Так как отдельно использовать этот класс - можно, но это не правильно?
Вообще нехорошо возвращать более чем интерфейс, но это вопрос философии
DS
А, ну и еще при проксировании интерфейса будут проблемы
СП
В общем лучше делать так метод, как он в интерфейсе прописан. Жить будет проще
DS
В общем лучше делать так метод, как он в интерфейсе прописан. Жить будет проще
да
AP
Вообще нехорошо возвращать более чем интерфейс, но это вопрос философии
Я бы сказал, что это зависит от многого и особенно это библиотека или какой-то свой код. При библиотеке (public API) лучше возвращать абстракцию, чтоб легче было изменять свой код без BC, при своем коде возвращать конкретную реализацию, так как это дает больше возможностей, как бы, ты знаешь реализацию и что там есть (дополнительные методы).
DS
Arman Poghosyan
Я бы сказал, что это зависит от многого и особенно это библиотека или какой-то свой код. При библиотеке (public API) лучше возвращать абстракцию, чтоб легче было изменять свой код без BC, при своем коде возвращать конкретную реализацию, так как это дает больше возможностей, как бы, ты знаешь реализацию и что там есть (дополнительные методы).
Как раз абсолютно наоборот, во внутряке фреймворка еще можно вернуть реализацию, а в своем приложении за возврат реализации свыше интерфейса надо бить по рукам.
DS
Если мы декларируем следование паттерну depenedency injection, то мы должны придерживаться два простых правила:
1. Однин класс - один интерфейс.
2. Все публичные методы класса являются частью интерфейса.
1. Однин класс - один интерфейс.
2. Все публичные методы класса являются частью интерфейса.
Недавно вот писал об этом
AP
Я же говорю если Public API - интерфейс, если internal для фреймворка тогда без разницы. Для Public API если возвращать реализацию, то даже маленькая поправка можеть стать BC. Ну в своем коде там уже все зависит от масштабов приложения и реализации. В маленьких проектах коммерчески не выгодно все под реализации делать, время там дороже.
AB
Если мы декларируем следование паттерну depenedency injection, то мы должны придерживаться два простых правила:
1. Однин класс - один интерфейс.
2. Все публичные методы класса являются частью интерфейса.
1. Однин класс - один интерфейс.
2. Все публичные методы класса являются частью интерфейса.
где про это почитать?
AP
По аргументам почти всегда желательно принимать абтракцию, а не конкретную реализацию
DS
где про это почитать?
Нигде, это правило на основе практики которое позволяет избежать довольно частой ошибки, которую совершаю даже опытные разработчики, и если это было пропущено в прод, то это часто создает огромные проблемы при замене реализации, вплоть до перепроектирования архитектуры.
DS
Яркий пример - провайдер листенеров, за который мы с @samdark спорили, но все таки пришли к компромису, чтобы не тянуть метод attach, которого нет в интерфейсе.
А
Косяк не в том, что метода нет у интерфейса, а в том, что нет интерфейса под метод
А
Точнее нет интерфейса под ту цель, ради которой нужен этот метод
DS
Косяк не в том, что метода нет у интерфейса, а в том, что нет интерфейса под метод
Правильно, хочешь добавить публичный метод - создавай новый интерфейс
А
Правильно, хочешь добавить публичный метод - создавай новый интерфейс
Это figовая тема
DS
Но в случае PSR интерфейсов это бессмысленно, поэтому реализации этих интерфейсов должны полностью соответсовть интерфейсам по публичным методам.