Профиль пользователя заблокирован сроком с 10 апреля 2022 г. и навсегда по причине: систематические нарушения правил сервиса
Ответы пользователя по тегу Паттерны проектирования
  • Кто знает хорошие уроки про PHP,MVC?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Ответ написан
    Комментировать
  • Что лучше редиректы или цепочка обязанностей?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Что лучше, ходить пешком или кеды? Как это согласуется с КПСС?

    Вопрос бессмысленный.
    Если нужен редирект, то надо делать редирект.
    Если редирект не нужен, то не делать.
    К ООП все эти страдания не имеют никакого отношения.
    Ответ написан
  • Почему Service Locator это зло и что использовать вместо?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Все эти страшные слова - они на самом деле всегда про одно и то же - про связность. Когда ты хардкодишь внутри класса вызов какого-то конкретного сервиса - ты намертво к нему привязываешься. И чтобы поменять сервис на другой, ты будешь вынужден поменять код класса. Окей, поменял. И тут же в другом месте, где этот же класс использовался, что-то сломалось! И что теперь? Делать два класса, которые различаются одной строчкой? Нет конечно. А как тогда использовать один и тот же класс для обработки разных входящих данных (или одних и тех же данных, но разными способами)? Сделать его поведение изменяемым. То есть сделать изменяемыми те инструменты, которыми он пользуется - т.е. его зависимости.

    Поэтому все зависимости обычно передаются через конструктор (и поэтому и называются инъекция зависимостей.)

    Таким образом мы можем менять поведение класса, не меняя его код

    Но тут надо понимать, что всё это работает только при правильном применении ООП. А точнее просто при применении ООП. Потому что 98% "ООП" кода, который пишется на РНР - это голимая процедурщина, даже если она обёрнута в классы и методы. Если у тебя метод класса представляет из себя стену кода, которую ты тупо перенёс из файла, инклюдившегося в любимое похапешное спагетти - то это не ООП. Это та же процедурщина, вид сбоку. И смысл использования dependency injection ты с ним не почуствуешь. Будешь конечно применять, но в качестве карго культа - потому что тебе это на тостере написали.
    А вот когда твой код начнет становиться действительно объектным - тогда стразу станет понятнее.


    Похожим на сервис локатор является сервис- или DI-контейнер. Используемый вручную, он является тем же самым сервис локатором. Поэтому вручную его никогда не надо вызывать - что и запрещается в симфоневских конроллерах - а только для автоматического создания классов. В МВЦ у тебя ведь очень многие объекты создаются автоматом - сущности, контроллеры. И вот для того, чтобы при автоматическом создании экземпляра класса у тебя были на руках все требуемые сервисы - и нужен контейнер.

    Соотвтственно, ответ на вопрос "что использовать?" очень простой:
    - при ручном создании экземпляра объекта, все зависимости передавать в него через конструктор, а не получать "из воздуха" в коде.
    - при автоматическом создании экземпляра объекта, использовать dependency injection container

    В этим смысле очень полезно освоить Симфони - строгий фрейворк, в котором нет сервис локатора и в котором запрещено пользоваться контейнером напрямую.
    Ответ написан
    4 комментария
  • Можете объяснить зеленому что такое MVC?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Господи, в который раз-то уже?

    Вообще-то надо указывать конкретный язык приложения, поскольку реализации паттерна отличаются весьма значительно.
    Для асинхронного клиент-серверного НТТР реализация будет такая:

    Самое главное, что надо понимать про эмвэцэ.
    Это не 50% твоего приложения. И даже не 10.
    Это тонюсенькая прослоечка, которая обслуживает только один канал общения твоего приложения с внешним миром - браузер. Есть и другие каналы, их много.

    Исходя из этого, получается что
    • Модель входит в эту тройку чисто номинально. Поскольку это и есть все твое приложение, только без интерфейса. И к модели обращаются не только веб контроллеры, но и консольные скрипты, REST контроллеры, сервер очередей и прочее. Отсюда становится понятно, что "модель - это запросы в БД в основном-то" - это дикая чушь.
    • Контроллер - это, как правильно нарисовано на картинке в соседнем ответе - это такая официантка, подай-принеси. Принять запрос от НТТР клиента, преобразовать в понятный для модели вид, запросить модель, получить ответ, вернуть что-нибудь клиенту. Также может заниматься чисто браузерными заморочками типа заголовков, авторизации и пр.
    • Вью - если модель вернула что-то для показа клиенту, то вью это превращает в понятный для браузера вид.
    • Роутер - не упоминается, но незримо присутствует. Преобразует НТТР адреса в вызовы контроллеров.

    Традиционно рекомендую доклад Дмитиря Елисеева с ПХП Раша 2019, там все раскладывается по полочкам.

    5dc1688cad3db637954994.png
    Ответ написан
    7 комментариев
  • PHP. Singletone для pdo. Как реализовать?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Ответ на этот вопрос очень простой.

    - Если ты пишешь процедурный код, то в синглтоне нет никакого вреда, а только одна польза.
    - Если же ты пишешь объектный код, то синглтон тебе просто не нужен, поскольку в объект при создании всегда можно передать инстанс класса для работы с БД и присвоить переменной класса.

    по поводу реализации

    1. Как уже сказали выше, какой-то странный метод getInstance(). Если каждый раз вызывать с парасетрами, то какой вообще смысл в синглтоне? Сделай хотя бы два метода, один коннект, а второй гетинстанс.
    2. Не очень понятно почему две статические переменные, и какая за что отвечает. почему бы не оставить одну?
    3. Если уж делать синглтон, то лучше избавляться от лишней писанины, и обращаться напрямую к методам для работы с БД: `DB::insertId()` будет поудобнее, чем `DB::getInstance()->insertId()`
    4. Учитывая неудобство метода PDO::execute(), будет полезным подправить классиков и добавить метод, который будет выполнять запрос с параметрами и вернет стейтмент. Пример можно посмотреть здесь: https://phpdelusions.net/pdo/pdo_wrapper
    Ответ написан
    Комментировать
  • Чем паттерн Repository отличается от DataMapper?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Это два абсолютно разных паттерна.

    DataMapper - это то, что традиционно неправильно называют моделью. Тупо мостик между БД и объектом: считать данные из БД и записать в объект, сохранить объект в БД. Фактически CRUD. Способ автоматизировать рутинные операции. Моделью являться не может в силу изначальной ограниченности.
    Другими словами, это универсальный код, подходящий для работы с любыми объектами. Инструмент для работы с БД. Все его методы одинаковы для любых объектов.

    Репозиторий - это то, что на самом деле является моделью - набор методов, реализующих бизнес-логику приложения. Метод в репозитории может включать в себя десяток разных запросов к БД для получения набора данных, необходимого в приложении, плюс их обработку.
    В отличие от DM, репозиторий содержит также уникальные методы, которые отражают конкртеные нужды конкретного модуля приложения.
    Ответ написан
    1 комментарий
  • Php PDO database singleton. Какой вариант выбрать?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    По первому варианту:
    1. Зачем здесь нужен класс Database?
    2. У тебя будет только один класс во всем приложении? или больше? А сколько будет коннектов после new myclass и new myclass2?

    По второму.
    Высоколобые не любят синглетон. Чем-то он им там с тестированием мешает. Плюс религиозная нетерпимость. Так что используй статический синглтон только если у тебя код организован в виде классического процедурногоговнокода.

    Если же у тебя все в виде кошерной иерархии классов, то, как замечено в другом ответе, передавай соединение в класс, а не создавай его каждый раз заного.
    function __construct($db)
        {
            $this->db = $db;
        }
    Ответ написан