Задать вопрос

topuserman

Комментарии

  • Dependency Injection Container, попробовал на практике - не понял смысла?

    @topuserman Автор вопроса
    Спасибо большое! Стало более понятно.

    например некий провайдер более чем в 1 месте или некий Sender в 20 местах по всему приложению. И упростить к ним доступ.


    А вы не знаете репозитории на гитхабе или где можно посмотреть примеры, почитать код, чтобы понять, что и когда используется, и посмотреть на реальном примере ? Или если возможно смоделировать такой пример, где будет понятно преимущество контейнера и вариант без него - буду очень благодарен!

    также, мне на форуме, к которому прикладывал ссылку, мне написали, что основное преимущество DI-контейнера - автовайринг, насколько я понял это из этого сообщения:

    Одно из преимуществ - автоматическое внедрение зависимостей.
    Это обязательное условие для контейнеров?

    Ну да, он для этого и нужен. Без него пришлось бы все зависимые объекты вручную создавать/передавать.


    это на самом деле так? Тогда для чего контейнеры без автовайринга, которых достаточно много и они очень популярны...


    Но вы можете упростить, и вынести инициализацию контейнера в абстракцию — в некий класс App/Kernel и там это делать, а в точке входа инициализировать не контейнер раз за разом, а именно конкретное приложение.


    Будьте добры, пример пожалуйста. Не совсем представляю, как я могу в классе азполнить контейнер сервисами, сконфигурировать их и что дальше? Метод класса должен вернуть контейнер ? Или как ?
    Написано

  • GuzzleHttp, как записать информацию дебага в переменную?

    @topuserman Автор вопроса
    Спасибо большое!

    Если данные не превысят 2Мб, они как любая переменная будут находится в оперативной памяти


    Вы наверное спутали с php://tmp.

    В этом случае все норм будет?
    Т.е. не будут ли случаи, когда я записываю данные в php://memory и не успел их считать еще оттуда, какая-то другая библиотека окажется, что тоже туда что-то запишет - в этом случае накладок не будет? Или при инициализации, у каждого свой поток?
    Написано

  • Как правильно организовать уровни исключений и логирование?

    @topuserman Автор вопроса
    dmitriy, понял, спасибо большое за объяснение!
    Написано

  • Как правильно организовать уровни исключений и логирование?

    @topuserman Автор вопроса
    dmitriy, спасибо большое! Так понятнее стало.

    в моем примере ни разу не применил swicth-case не понимаю и зачем он вам


    имел ввиду, что придется все возможные классы исключений, таким образом перебирать:

    try{
       ...
   }
   catch(ClassException1 $ex)

   }
   catch(ClassException3 $ex)

   }
   и т.д.


    Насколько я понял, необработанные исключения можно отлавливать через set_exception_handler.



    В какой момент мне записывать в лог?

    в момент ловли исключения






    У меня в голове такое представление (не знаю, можно ли делать так, и хорошая ли это практика):

    создаем основной класс исключений, и в нем переопределяем конструктор, в котором будут данные из метода getMessage() добавляться в лог. Также создать доп. метод, в котором при необходимости можно будет передать другое сообщение для лога ( если не устраивает формат сообщения из getMessage() ).

    Также хотелось бы завести 3 интерфейса, как писал в вопросе

    UnloggedInterface - этим интерфейсом помечаются эксепшены, которые не надо логировать вообще.

    PreloggedInterface - этим интерфейсом помечаются эксепшены, которые необходимо логировать в любом случае: неважно, обработаны они или нет.

    OutableInterface - этот интерфейс помечает эксепшены, текст которых можно выдавать пользователю: далеко не каждый эксепшн можно вывести пользователю.


    и в зависимости от того, какой интерфейс имплементируется, появляется у класса исключения те возможности, которые описал выше (логирование из конструктора и доп. метод).

    Только как это связать все, чтобы была грамотная архитектура - не знаю.
    Написано

  • Как правильно организовать уровни исключений и логирование?

    @topuserman Автор вопроса
    Спасибо! Но мне не понятен такой момент:

    Например разрабатываю некий функционал интеграции с 1с, в процессе разработки можен возникать множество Исключительных ситуаций.

    Например:
    1. исключения, которые не требуют обязательной обработки.
    2. исключения, которые нужно только обработать
    3. исключения, при возникновении которых нужно обязательно сообщить администратору - добавить инфу в лог. (Не важно обработано исключение или нет)

    С первыми двумя пунктами, мне немного понятно как быть. А вот с третьим непонятно, а именно:

    В какой момент мне записывать в лог?

    Если в момент, когда выбрасываю исключение?

    Это нужно делать перед throw new Exception, или нужно в моем классе Exception реализовать методы добавления в лог в зависимости от того, како интерфейс имплементирую (UnloggedInterface, PreloggedInterface и т.д.)?

    А как быть с исключениями, которые не обработал?

    Если весь функционал обернуть в try - catche, то мне там придется десятки swicth-case перебирать классы экзепшином, чтобы понимать, с каким исключением что делать..
    Написано

  • Удалить белый цвет и его оттенки с помощью PHP?

    @topuserman
    Посмотри ответ ниже. Лучше брать (r + g + b) / 3
    Написано