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