по хорошему класс никогда не должен ничего просить

dont call us, we call you

Он может просить, если сразу ставится условие что ответ может прийти не скоро или вообще никогда

Он может просить, если сразу ставится условие что ответ может прийти не скоро или вообще никогда

ну это уже про message passing)

Это даёт пространство для манёвра

ну это уже про message passing)

А ну да))

Он может просить, если сразу ставится условие что ответ может прийти не скоро или вообще никогда

и ты тут тоже )))

Ага)

просто я видел что в сишарпе когда просишь зависимость в конструкторе то можно аттрибутом попросить себе чтото особенное :) и вот задумался - а зачем. класс то сам не должен знать

Это конкретная фишка IoC контейнера. Кому-то удобнее атрибутами, кому-то во флюенте всё описывать.

Это конкретная фишка IoC контейнера. Кому-то удобнее атрибутами, кому-то во флюенте всё описывать.

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

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

атрибуты это не сорсы класса

это метаданные, они биндятся на класс, да, но не являются его частью

файлик с сурсами - это не про классы. файлик это файлик.

они в одном текстовом файле с сорцами класса :)

и компилятся в одну сборку и т.д.

ну вот да - и тут как тебе удобно) есть плюсы и минусы. универсального решения нет

с точки зрения всяких там принципов в целом ничего не нарушено (почти).

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

с точки зрения метрик потенциальных (сколько файл трогали) могут быть проблемы. но тут то что @mkusher сказал

у дяди Боба был такой принцип (еще до SOLID) - принцип стабильных зависимостей (Stable Dependency Principle). Он чуть поясняет куда должны быть направлены стрелочки зависимостей и если подумать многое становится чуть логичнее

у дяди Боба был такой принцип (еще до SOLID) - принцип стабильных зависимостей (Stable Dependency Principle). Он чуть поясняет куда должны быть направлены стрелочки зависимостей и если подумать многое становится чуть логичнее

Интересная концепция

Не думал об этом с такой стороны

Роберт Мартин будет на лараконе :))) мне почемуто смешно :)

там среди оригинальных надцати принципов много хороших, но маркетинг взял верх и остались только эти 5)

Роберт Мартин будет на лараконе :))) мне почемуто смешно :)

а мне интересно) я его мнения относительно php не знаю))

ну на симфониКон(или как они там называются) я бы понял. но не лараконе же :) где господствуют принципы RAD. User::create($request->all()) и поехали.

так User::create($request->all()) не плохо само по себе

ну на симфониКон(или как они там называются) я бы понял. но не лараконе же :) где господствуют принципы RAD. User::create($request->all()) и поехали.

ты же понимаешь что RAD это миф?)

ну то есть сам термин RAD он.... бесполезен..

ну да, типа делай так чтобы было удобно

звучит как делай хорошо)

ну мол идея ж простая: - изначально у нас есть идея и нам надо запилить ее максимально быстро и дешево - если вдруг идея выстрелила и надо скейлиться (как в плане производительности/пропускной способности так еще и в плане людей, размера команды, менеджмента, возможности выкатывать фичи) - тут другие правила. И да, тут нет смысла заморачиваться о мелочах - типа надо еще 100 серваков - нет вопросов!1 потом оптимизируем! Инвесторы нам дали пару лямов) - ну и дальше стабилизация конкретного скоупа где уже можно уменьшать издержки

и сложность тут в том что бы пережить вторую фазу

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

ну короч на эту тему можно Кента Бэка послушать про его X3 (Explore, Expand, Extract)

и потом лекцию с фейсбука, где он думает, что можно идти с другой стороны?)

и потом лекцию с фейсбука, где он думает, что можно идти с другой стороны?)

extract -> expand -> explore?

не смотрел)

это все таже лекция

он ж там две стратегии попадания в нужную точку рассматривает

(я не всю осилил)

https://www.youtube.com/watch?v=YX2XR73LnRY

ну мол идея ж простая: - изначально у нас есть идея и нам надо запилить ее максимально быстро и дешево - если вдруг идея выстрелила и надо скейлиться (как в плане производительности/пропускной способности так еще и в плане людей, размера команды, менеджмента, возможности выкатывать фичи) - тут другие правила. И да, тут нет смысла заморачиваться о мелочах - типа надо еще 100 серваков - нет вопросов!1 потом оптимизируем! Инвесторы нам дали пару лямов) - ну и дальше стабилизация конкретного скоупа где уже можно уменьшать издержки

я недавно целый день вещал про это примерно. https://devconf.ru/ru/offers/offer/378 и моя мысль была, что в конкретно ларавель.. там народ просто не понимает как бороться со сложностью когда проект растет. все "ларавел бест практис" направлены на то как быстро чтото запилить. а не на то, как потом это все поддерживать.

он ж там две стратегии попадания в нужную точку рассматривает

надо пересмотреть

я недавно целый день вещал про это примерно. https://devconf.ru/ru/offers/offer/378 и моя мысль была, что в конкретно ларавель.. там народ просто не понимает как бороться со сложностью когда проект растет. все "ларавел бест практис" направлены на то как быстро чтото запилить. а не на то, как потом это все поддерживать.

тут сложность в том что бы люди начинали оценивать окупаемость решений

ну и еще - я сталкивался с людьми которые просто не хотят думать. типа "опиши как делать и я только так и буду делать"

что уже не может быть "оптимально"

ну и еще - я сталкивался с людьми которые просто не хотят думать. типа "опиши как делать и я только так и буду делать"

эт да...

ну да, у тебя всегда есть некая текущая ситуация, некая проблема и большое число решений

управление рисками это отдельная жирная тема....

ну да, у тебя всегда есть некая текущая ситуация, некая проблема и большое число решений

а еще - как завещал Кей - есть множество ложных путей которые вырастают из того что сейчас )

да)

я недавно целый день вещал про это примерно. https://devconf.ru/ru/offers/offer/378 и моя мысль была, что в конкретно ларавель.. там народ просто не понимает как бороться со сложностью когда проект растет. все "ларавел бест практис" направлены на то как быстро чтото запилить. а не на то, как потом это все поддерживать.

а записи есть где-нибудь или хоть какие-то тезисы\примеры? интересно.

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

и конкретно вопрос про сервис локаторы возник из этого. когда пишешь чтото.. хочется более веско обьяснить зачем надо юзать DI. а не сервислокатор

но в принципе, теперь обьяснить смогу. в какойто момент проект растет и необходимость в DI возникает сама собой. потому что юнит-тесты. потмоу что возможность скрытвать зависимости позволяет делать божественные классы. так себе аргументы, но их значимость с ростом проекта тоже растет

но в принципе, теперь обьяснить смогу. в какойто момент проект растет и необходимость в DI возникает сама собой. потому что юнит-тесты. потмоу что возможность скрытвать зависимости позволяет делать божественные классы. так себе аргументы, но их значимость с ростом проекта тоже растет

а зачем юнит тесты? есть же интеграционные)

им норм

а зачем юнит тесты? есть же интеграционные)

дада :))

> потмоу что возможность скрытвать зависимости а ну ты чуть-чуть задел... ладно

а зачем юнит тесты? есть же интеграционные)

Регулярно случается так что некоторые части кода нужно тестировать более тщательно чем обычно

Регулярно случается так что некоторые части кода нужно тестировать более тщательно чем обычно

это был типа сарказм)

ну я думаю, что это сарказм был

да :)

Регулярно случается так что некоторые части кода нужно тестировать более тщательно чем обычно

а мне казалось что юнит тесты это про дизайн а не про проверки... проверки на фиксированных значениях вообще чет как-то не очень)

ну я думаю, что это сарказм был

Блин ?

ну да, юнит-тест это проверка не кода, а дизайна

а мне казалось что юнит тесты это про дизайн а не про проверки... проверки на фиксированных значениях вообще чет как-то не очень)

Граничные случаи

обычно

типа попробуй поюзай что сам напилил и пострадай

Граничные случаи

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

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

Запили видос или курс. Будет клево. Имхо в книге можно хорошо осветить тезисы и обоснования, но освещать листинги в книге не айс

ну вот штуки для которых выдумывают всякие rust-ы

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

на ту аудиторию на которую ты нацелен хорошо подойдет ютуб канал, будешь хипстером с просмотрами, просить лайки поставить)

что-то типа fun fun function и подобное

на ту аудиторию на которую ты нацелен хорошо подойдет ютуб канал, будешь хипстером с просмотрами, просить лайки поставить)

хорошо оскорбил :) молодец :)

Я даже готов купить)

хорошо оскорбил :) молодец :)

не ну че, не лестплэи/летсватчи/реакции, уже не совсем ущербно)

только если это не будет стоит $4000 за трехдневный курс где-нибудь в СантаМонике)

только если это не будет стоит $4000 за трехдневный курс где-нибудь в СантаМонике)

мне вот эта идея нравится больше чем Сергея :) все таки мечта должна быть большой! :))

мне вот эта идея нравится больше чем Сергея :) все таки мечта должна быть большой! :))

Ты наверное не заметил маленькое отрицание в виде предлога НЕ :)

да. и сделал это намеренно :)

мне вот эта идея нравится больше чем Сергея :) все таки мечта должна быть большой! :))

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

или ты думаешь тебя все просто так звать будут?)

не ну че, не лестплэи/летсватчи/реакции, уже не совсем ущербно)

Летсплей про архитектуру приложения

С донатами

пишем плагины для майнкрафта на laravel используя DDD

донатим на <feature name> в <language name>

на принятие RFC в пхп7.3

на принятие RFC в пхп7.3

https://wiki.php.net/rfc/generics

https://wiki.php.net/rfc/generics

ну в 7.3 уже вроде как фича фриз должен быть

в 8-ке может будут

а может и нет)

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

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

Кстати, сегодня заюзал :) В callback для usort

мне всегда хватало нечитаемого однострочника)

Почему?