Паттерн Фабрика на реальном примере в PHP
ฝัง
- เผยแพร่เมื่อ 13 ก.ย. 2024
- #php #designpatterns #programming #программирование Рассказываю как с помощью фабрики избежать дублирования кода.
Старался не пересказать википедию, а показать пример с пользой от использования паттерна.
Друзья, я решил немного сменить формат, приглашаю на новый канал / @live_coding
Немного не понял почему хелпер отдает фабрику конкретного сервиса, если этот хелпер может сам выступать в роли фабрики, которая возвращает уже непосредственно нужный нам экземпляр класса оплаты. Какая-то усложненная фабрика получилась...
Хелпер используется в качестве какого-то контекста, в рамках которого по коду из paymentType определяет фабрика. По хорошему такое выносится в конфигурационный файл или накрайняк сразу привязывается фабрика к заказу. Авто реально упростил. Основной смысл видео в фабрике.
большое спасибо! очень доходчиво, как для новичка, было всё понятно. моё почтение автору ))
Я уже более 5-ти лет занимаюсь программированием и мне всегда было интересно почему дублирование кода это плохо, а дублирование файлов с этим самим кодом хорошо))))))
полагаю,потому,что если код дублирается в файле,то чаще всего это предполагает то,что повторяющийся код будет прочитан,либо бесконечные кейсы/ифелсы,что нагромождает и делает нечитабельным
Я тоже не понял, у нас была раскладушка условий, теперь у нас раскладушка условий и еще несколькоко, Фабрик несколько интерфейсов, кода стало больше
Все же непонятно, зачем нужна фарбрика в этом случае? Почему в том же хелпере, сразу не возвращать объект реализующий PaymentInterface. Ничего же не измениться, при появлении нового способа оплаты, создаем новый файл - объект и добавляем его в хелпер, который вернет его. Зачем это нужно делать через фабрику? Почему именно фабрика, которая инититься через хелпер, должна нам вернуть объект PaymentInterface, почему сразу из хелпера не вернуть этот объект?
у меня такой же вопрос :D
Чтоб не раздувать хелпер лишними условиями. Хелпер выдает фабрику по типа оплаты, а уже фабрика может выдать разные реализации. Если брать пример из жизни на пальцах - для безнала в зависимости от типа карты выбрать реализацию для нее, или в зависимости от суммы, выбрать более дешёвый процессинг.
@@nickyx3 Т.е. если расширения сервиса не предвидится, то и фабрика сервиса не нужна? (Рассматривая пример не всегда видна глубина проблемы. Спасибо за пояснение.)
@@fitter2boss72 В зависимости от стиля и правил принятых в команде. В теории можно вообще на нативном php всё писать 🙂
Вообще, чем больше я тут погружаюсь в лару, тем больше вопросов к некоторым вещам. Из последнего - почему redirect($url,301) выдает код 200 а редирект в теле ответа, а мне надо 301 именно в хидерах, пришлось обойти через response('',301)->header('Location',$url). Но выглядит как костыль
@@nickyx3 когда Тейлор удалил все пользовательские issue в репе ларавел, все стало ясно)
Огромное спасибо, супер доходчиво и понятно)))
Идеально было бы, если бы не было никаких if и case. Например подгружался бы объект, который был выбран при оплате.
А так, всеми этими case, получается тот же if, только в другом виде.
Таки образом, не надо править код, если потребуется добавить или удалить способ оплаты.
это можно сделать, например, если мнемоника типа явно коррелирует с именем класса, например "sber" -> SberPayment, либо где-то хранить таблицу соответствия
Мне кажется либо правила open closed нарушена либо паттерн неправильно реализована
Так в классе PaymentHelper опять же куча ветвлений. В чём тогда вообще смысл? Мы всё равно не избавились от ветвлений, а только заменили if else на switch
Полезный ролик. И теория и пример
спасибо!
По-моему тут нужна не фабрика а стратегия
в чем проблема просто сделать один класс или функцию payment, в которую передавать вместе с заказом параметр например paymentType и внутри по этой развилке через if/case производить нужные действия? это же элементарная логика. я понимаю зачем можно разнести каждый тип оплаты в отдельный класс, но зачем городить еще интерфейс, хелпер и называть это "паттерн фабрика" - не понимаю.
как ты схему включил в ide? на 8:40)))
Хотелось бы посмотреть про все паттерны, а так же ссылку на гит с кодом конкретно урока)
в планах)
Патерн стратегия наверное лучше подойдет?
Да очень схожи
Смотря на схему получается что мы добавляем сущности и расширяем систему, но в классе где описан switch мы изменям. А если избавится от точки изменения? допустим сделать более динамический способ создания сущности и добавлении оплаты в фабрику?
Хоть один нормальный человек показывает на реальных примерах,,, а то рассказыватели про секс рассказывают на примере резиновой бабы постоянно.
Выкладывая видео, предварительно глянь - как будут его видеть те, для кого ты стараешьсяю
То есть теперь у нас не только раскладушка ифов а раскладушка кейсов + еще несколько файлов. Я так и не понял зачем
хм, в итоге мы пришли к switch - case хмм.. чот я не понмю такой реализации, наоборот старатются с помощью композиции и наследования уйти от всяких if и подобных ему... Не очень врубался в этот пример, но пришло в голову, что в самом PaymentHelpere может возникнуть необходимость дополнительных методов, в которых придётся делать то-же самое, т.е. для общение с классами продуктами юзать этот присловутый switch-case. Почему нельзя сделать PaymentHalper абстрактным, определить в нём метод получения PaymentMethodGetter который должны будут реализовывать его дочерние классы, а именно VtbPayment , TcsPayment, SberPayment и уже ОНИ будут возвращать эти самые new TcsPaymentFactory(), new SberPaymentFactory() и так далее?
Я обязательно напишу с чем я не согласен, когда пойму с чем, именно, я не согласен:)
Я тут не вижу логику. Мы IF заменили на switch. И плодим не IF, а плодим case.
В одном файле плодили IF, - сделали фабрику и в другом файле плодим case. И в чем прикол? оО?
У меня PHP_EOL просто пробел ставит, а не на новую строку переносит
Помнится эта константа переопределяется через ini файл, ну и к тому же перенос строки в ответе с content-type:text/html и будет выглядеть как пробел
Ну намудрил