Автовайринг (почти как в symfony) своими руками?

BoShurik, хотелось бы разобраться, как можно самому сконфигурировать

Автовайринг (почти как в symfony) своими руками?

BoShurik, да, это будет для ручного конфигурирования.

проблема в том, чтобы автоматически регистрировать все классы из определенной директории в качестве сервисов.

наковырял такой класс - Symfony\Component\DependencyInjection\Loader\Configurator\PrototypeConfigurator
сейчас буду изучать, похоже на то, что нужно, но не уверен пока.

Автовайринг (почти как в symfony) своими руками?

BoShurik, да, я в эту сторону и двигуюсь, но основная сложность в том, чтобы сделать автоматическую регистрацию классов в качестве сервисов.

В симфони за это отвечает кофигурация:

App\:
        resource: '../src/'
        exclude:
            - '../src/DependencyInjection/'
            - '../src/Entity/'
            - '../src/Kernel.php'

Но какой компонент, или участок кода отвечает за обработку этого, так и не нашел..

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

Как применить array_reduce?

SADFGHJAETJER, у кажного объекта "A" - есть стоимость - cost.
При вызове метода getMaxSkill, вторым аргументом передают сколько у меня всего есть денег.
В результате, если среди объектов есть по стоимости, подходящие мне, то я должен получить среди них тот объект, у которого skill больше.

Какая разметка нужна при установке на ubuntu 20.04 на ssd+hdd?

Adamos, понял, спасибо большое!
А при установке, если hdd монтировать в home, для него нужно выбирать первичным или расширенным ?

Какая разметка нужна при установке на ubuntu 20.04 на ssd+hdd?

Adamos, т.е. ручное монтирование hdd в /home после установки тоже самое, что я бы делал при установке ?

Какая разметка нужна при установке на ubuntu 20.04 на ssd+hdd?

Спасибо!
Уточните пожалуйста, если монтировать этот диск, то отличается ли его работа (возможно по производительности), если бы я выбрал hdd при установке для директории /home ?

Какая разметка нужна при установке на ubuntu 20.04 на ssd+hdd?

Спасибо!
Уточните пожалуйста, если монтировать этот диск, то отличается ли его работа (возможно по производительности), если бы я выбрал hdd при установке для директории /home ?

Какая разметка нужна при установке на ubuntu 20.04 на ssd+hdd?

Спасибо!
Уточните пожалуйста, если монтировать этот диск, то отличается ли его работа (возможно по производительности), если бы я выбрал hdd при установке для директории /home ?

Как архитектурно лучше решить такую задачу (с точки зрения ооп)?

возможно, ошибаюсь, и как раз через Адаптер и решается моя проблема..))

Как архитектурно лучше решить такую задачу (с точки зрения ооп)?

Василий Банников, согласен, неправильно выразился по декоратору, не упомянув про интерфейсы.

Но если в нашем случае, есть интерфейса (потребителя, которому нужен какой-то особый интерфейс, под который мы хотим изменить).

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

Если бы у меня был клиентский код, которому нужен был интерфейс А, а у меня интерфейс Б, то тогда нужен был бы адаптер для интерфейса А, который зависел бы от Б.

Как архитектурно лучше решить такую задачу (с точки зрения ооп)?

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

Как архитектурно лучше решить такую задачу (с точки зрения ооп)?

Декораток скорее-всего не то, т.к. он всего-лишь добавляет новые возможности в существующие методы.

А мне нужно кроме добавления нового функционала к одному методу, еще и его новый метод создать.

ООП: Правильно ли архитектурно так делать?

M_E_M_F_I_S, спасибо,
по поводу code-style - это вкусовщина)
достаточно частая практика, когда переменные и свойства объекта - в snake_case, а остальное в cameCase.

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

да и сам psr специально так и пишет:

This guide intentionally avoids any recommendation regarding the use of $StudlyCaps, $camelCase, or $under_score property names.

Whatever naming convention is used SHOULD be applied consistently within a reasonable scope. That scope may be vendor-level, package-level, class-level, or method-level.

ООП: Правильно ли архитектурно так делать?

Спасибо!
А если некоторые объекты могут в себе логику содержать, то это же ведь уже не дто? Так делать нельзя? Нужно другой слой создавать?

ООП: Правильно ли архитектурно так делать?

profesor08, тогда будет два похожих объекта..
Order и OrderFields, которые будут решать одну и ту же задачу - это доступ к свойствам заказа. Или не так понимаю?

ООП: Правильно ли архитектурно так делать?

Каким объектом? В нём данные самого заказа - идентификатор, дата создания и десяток других. Передаю массивом, чтобы конструктор не городить.
А если что-то из этого массива можно выделить в отдельный объект - то таки делаю. Например с покупателем, списком товаров, доставкой и оплатой.

Нужен ли оркестратор для запуска одного контейнера для отдельном сервере?

т.е. нужен оркестратор, чтобы ручками это не делать?

Нужен ли оркестратор для запуска одного контейнера для отдельном сервере?

почему? в чем именно сложность может быть?

Нужен ли оркестратор для запуска одного контейнера для отдельном сервере?

а docker-compose может разворачивать одновременно на нескольких серверах?