GE
Смотря с чем сравнивать...
И смотря какая задача
Size: a a a
2020 May 02
А
Смотря с чем сравнивать...
Я теперь понимаю, почему разработчики php не хотят перевести на многопоточный... это одна из всех вопросов
OK
John Travolta
Только трейты, а не интерфейсы
В интерфейсах нет реализации
В интерфейсах нет реализации
Я говорил о множественном наследовании, а не реализации
JT
В каких-то случаях лучше, в каких-то - не очень.
В множественном наследовании ведь тоже неудобства есть.
Представьте, что будет, если у обоих предков окажутся одинаковые методы? (проблема ромбовидного наследования)
Поэтому, по моему С++ давнишнему опыту, МН помогает тогда, когда сущности достаточно простые.
Для которых сервис жирно будет делать.
В множественном наследовании ведь тоже неудобства есть.
Представьте, что будет, если у обоих предков окажутся одинаковые методы? (проблема ромбовидного наследования)
Поэтому, по моему С++ давнишнему опыту, МН помогает тогда, когда сущности достаточно простые.
Для которых сервис жирно будет делать.
Если одинаковые методы, в пыхе в трейтах есть алиасы, при этом не меняя название метода оригинального там и там
TS
Коллега, вы меня с кем-то спутали, я вообще против множественного наследования, я за сервисную архитектуру топлю.
Я понял. Я не против ни сервисной архитектуры ни наследования (в виде трейтов и поведений).
У каждого решения есть своя граница применения.
Приходилось видеть проекты, в которых функционала-то на три копейки, и под два десятка сервисов.
Спрашиваешь - ты зачем это наделал?
а он такой: Ну паттерну соответствует...
Так что никогда не следует множить сущности без настоятельной на то необходимости.
Ибо усложнять просто, а упрощать сложно.
У каждого решения есть своя граница применения.
Приходилось видеть проекты, в которых функционала-то на три копейки, и под два десятка сервисов.
Спрашиваешь - ты зачем это наделал?
а он такой: Ну паттерну соответствует...
Так что никогда не следует множить сущности без настоятельной на то необходимости.
Ибо усложнять просто, а упрощать сложно.
JT
Oleg Kuzmenko
Я говорил о множественном наследовании, а не реализации
Я это понял)
Я говорю о том, что интерфейс не содержит методов с реализацией какой-то функциональности
Трейты содержат
Без реализации что наследовать?
Структуру класса?
Я говорю о том, что интерфейс не содержит методов с реализацией какой-то функциональности
Трейты содержат
Без реализации что наследовать?
Структуру класса?
GE
Я понял. Я не против ни сервисной архитектуры ни наследования (в виде трейтов и поведений).
У каждого решения есть своя граница применения.
Приходилось видеть проекты, в которых функционала-то на три копейки, и под два десятка сервисов.
Спрашиваешь - ты зачем это наделал?
а он такой: Ну паттерну соответствует...
Так что никогда не следует множить сущности без настоятельной на то необходимости.
Ибо усложнять просто, а упрощать сложно.
У каждого решения есть своя граница применения.
Приходилось видеть проекты, в которых функционала-то на три копейки, и под два десятка сервисов.
Спрашиваешь - ты зачем это наделал?
а он такой: Ну паттерну соответствует...
Так что никогда не следует множить сущности без настоятельной на то необходимости.
Ибо усложнять просто, а упрощать сложно.
Никогда не встречал проектов где заранее продуманная архитектура была бы не обоснована. Если знаний на применение паттернов нет, это конечно совсем другое.
TS
Никогда не встречал проектов где заранее продуманная архитектура была бы не обоснована. Если знаний на применение паттернов нет, это конечно совсем другое.
Да вот в том то и дело, что нет по факту никакой заранее продуманной архитектуры в реальных проектах.
Реальный проект сильно меняется даже во время реализации.
Реальный проект сильно меняется даже во время реализации.
TS
Никогда не встречал проектов где заранее продуманная архитектура была бы не обоснована. Если знаний на применение паттернов нет, это конечно совсем другое.
А как Вы думаете, люди писали сложный код до того, как были изданы те самые книги по паттернам, о которых Вы, скорее всего, говорите?
А
Холивар
А
Давайте жить дружно 😁
A
Ну ююишные эвенты может и не самые удобные. Но утверждение, что эвенты используются редко спорное.
Когда при добавлении товара например тебе нужно переиндексить товар в эластике, сгенерить превьюхи, зафиксировать какой пользователь создал или изменил товар, при изменении количества товара в наличии еще произвести манипуляции и прочая прочая логика. Ты будешь это все в сервисе писать? 5 раз пушить в очередь и делать 5 джобов?)) Написать свой диспатчер в простом виде и эвенты это дело 20 минут.
Когда при добавлении товара например тебе нужно переиндексить товар в эластике, сгенерить превьюхи, зафиксировать какой пользователь создал или изменил товар, при изменении количества товара в наличии еще произвести манипуляции и прочая прочая логика. Ты будешь это все в сервисе писать? 5 раз пушить в очередь и делать 5 джобов?)) Написать свой диспатчер в простом виде и эвенты это дело 20 минут.
Я тут случайно заглянул и скажу так ивенты - костыли, которые приходится применять когда проблематично это как-то подругому делать. Что касается подхода без нормальных сервисов и джобов, и очередей - на выходе будет тормозное битоиксоподобное, извиняюсь, говно.
И обработчики иветов по сути те же самые сервисы. По делу, лично я, редко этим пользуюсь. Но бывают задачи, вот например недавно делал построцессинг и там вообще пришлось до триггеров бд спускаться, по причинам описанных выше и по причинам особенностей обслуживания того овна.
В любом случае использовать обсервер без надобности - это такой себе подход.
Все, вставил свои пять копеек и убежал 😅
И обработчики иветов по сути те же самые сервисы. По делу, лично я, редко этим пользуюсь. Но бывают задачи, вот например недавно делал построцессинг и там вообще пришлось до триггеров бд спускаться, по причинам описанных выше и по причинам особенностей обслуживания того овна.
В любом случае использовать обсервер без надобности - это такой себе подход.
Все, вставил свои пять копеек и убежал 😅
GE
Да вот в том то и дело, что нет по факту никакой заранее продуманной архитектуры в реальных проектах.
Реальный проект сильно меняется даже во время реализации.
Реальный проект сильно меняется даже во время реализации.
Соболезную вам, ибо оно есть. Такое конечно встречается не часто, но хорошая архитектура, приемлемое качество кода, ревью, покрытие тестами это к счастью не миф и не сказка, даже в проектах в 10+ лет длиной
GE
А как Вы думаете, люди писали сложный код до того, как были изданы те самые книги по паттернам, о которых Вы, скорее всего, говорите?
Мир меняется, код меняется, подходы меняются
TS
Соболезную вам, ибо оно есть. Такое конечно встречается не часто, но хорошая архитектура, приемлемое качество кода, ревью, покрытие тестами это к счастью не миф и не сказка, даже в проектах в 10+ лет длиной
Конечно встречается, но на медленно изменяющихся и не передовых проектах. Наверное, такие бывают.
GE
Конечно встречается, но на медленно изменяющихся и не передовых проектах. Наверное, такие бывают.
Не правда, чтобы не быть голословным из последних с которыми работал в России maxposter.ru сейчас они вроде входят в состав авито
TS
Не правда, чтобы не быть голословным из последних с которыми работал в России maxposter.ru сейчас они вроде входят в состав авито
Сложно сказать что-то по непубличному проекту.
GE
Сложно сказать что-то по непубличному проекту.
А что можно сказать, это же чисто мое мнение, просто для того, чтобы не быть совсем голословным с гипотетическим проектом.
AI
На локалке все норм стоит open server а уже на серваке не понимаю как включить скрипт