Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Почитал в мануале про контракты. Там пишут, что если для тайп-хинтинга использовать интерфейсы(чтобы фреймворк подгружал нужные реализации) то это спасёт от переписывания кода при смене того что внедряешь или при смене апи внедряемой реализации. Пожалуйста объясните, я не могу понять почему не придётся переписывать код, если используешь интерфейсы.
Не в сети
Потому что один кусок кода не знает, что конкретно используется в другом куске кода - разные части приложения общаются на уровне интерфейсов.
Скажем есть класс Webmoney, который реализует онлайн-платежи через Webmoney, и есть контроллер Billing, который на сайте форму платежей и так далее показывает.
Если в контроллере Billing указан абстрактный интерфейс PaymentInterface, а класс Webmoney его реализует - то в будущем перейти на, скажем, Яндекс Деньги будет очень просто - надо будет написать класс Yandex, который будет реализовать тот же контракт PaymentInterface и где-нибудь в Laravel переключить Webmoney на Yandex - и все.
В контроллер ВООБЩЕ не придется заходить.
В реальном проекте - таких зависимостей могут быть десятки, и если все классы и контроллеры явно указывают Webmoney, а начальство скажет "а давай лучше PayPal" - может понадобиться в миллион файлов идти и править. И так каждый раз!
Ну и стоит добавить, что тестировать легче, когда используются контракты. Фейковый класс реализующий узкий набор методов - проще куда подставить.
Не в сети
Спасибо, я разобрался. Тут как говориться, выбирай из двух зол меньшее. Писать всё равно придётсья, но одно дело написать новую реализацию интерфейса, а другое перекопать все методы контроллера, которые затронуло изменение.
Не в сети
Спасибо, я разобрался. Тут как говориться, выбирай из двух зол меньшее. Писать всё равно придётсья, но одно дело написать новую реализацию интерфейса, а другое перекопать все методы контроллера, которые затронуло изменение.
Вот вот!
Это в английском называтся 'tightly coupled' - тесно связанный код, когда везде используются конкретные классы.
Когда используются только контракты - легко тестировать, легко заменять, легко реализовать модульную структуру и тд.
Это настолько меньшее зло, что почти не зло вообще
Не в сети
Страницы 1