А
Второй вариант с очень большой (подчёркнуто) натяжкой имеет право на жизнь.
Size: a a a
2021 September 12
ST
Первый вариант лучше получается или он совсем плох?
А
Первый вариант полное говно
ST
А во втором варианте, что надо поправить чтоб было хорошо?
А
Нужно посмотреть на тип. Если у него открытый конструктор, то это проблема. Это первое. Второе: добавится новый подтип, фабрику надо будет править. Третье: нет валидации наличия ключа в массиве.
В
ты бы еще к названиям прикопался
В
я саму идею описал
В
не больше
А
Хуевая идея. Я писал про
resolve – это дерьмовый совет.В
а как лучше?
В
если в классах нужен будет DI?
А
resolve – это не DI, это сервис-локатор. С этим вариантом https://t.me/laravel_pro/518025 с помощью контейнера симфони или ларки нет ничего сложного, чтобы использовать DI.АВ
Привет, подскажите как лучше сделать, возможно глупый вопрос, но у хочу спроектировать бд для агрегатора аэропортов.
Как лучше делать:
Таблицы «аэропорты», «самолеты», «пилоты» и т.д.
Или
«объекты», «тип объекта», «поля типа», «данные объекта»?
Как лучше делать:
Таблицы «аэропорты», «самолеты», «пилоты» и т.д.
Или
«объекты», «тип объекта», «поля типа», «данные объекта»?
В
а как ты в своем варианте избавился от второй проблемы что то я не вижу?
А
Где в моем варианте я буду править фабрику при добавление продукта?
В
если ты говоришь конкретно о классе фабрики то ты прав, его ты не будешь править но а при добавлении нового типа тебе всеравно придется прокидывать его в фабрику
В
я так понимаю ты и вызов фабрики както инкапсулировать будешь?
А
Это придется делать во всех вариантах (кроме симфони: там есть автоконфигурация). Но в моем варианте это безболезненнее всего, так как мой код не правится, правятся его данные. Это гарантирует стабильность.
В
просто как по мне удобно когда фабрика знает про все возможные варианты которые она может создать