то, что что - то для чего - то придумали - не значит, что так нужно делать

не юзкейсы у этого есть и не мало

то, что что - то для чего - то придумали - не значит, что так нужно делать

Мм, то есть в Гугле и Мс дураки работают?

но обычно не в рамках "оптимизации" а когда просто нет возможности дернуть

но обычно не в рамках "оптимизации" а когда просто нет возможности дернуть

Вот да, такое тоже бывает. Пермишонов может не быть банально.

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

вот тут Id token хорошо заходит.

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

Вот за этим и придумали

ну так то да, но можно по всякому это разрулить)

Вот за этим и придумали

Шоб я так работал Час думать: сделать vo или валидацию в сущности ?

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

Вот так может?

Шоб я так работал Час думать: сделать vo или валидацию в сущности ?

Это пет как хочу - так время трачу)

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

как сказал @zloyuser - надо разделять понятие "аккаунт" и "юзер".

Это пет как хочу - так время трачу)

А, ну тогда лан)

как сказал @zloyuser - надо разделять понятие "аккаунт" и "юзер".

Who is who?

ну то есть креды там, доступы и т.д. с профилем могут вообще никак не соотноситься, а то что для id token нужны какие-то данные - их можно запросить)

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

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

functional cohesion и все такое

У меня сейчас уже глаза слипаются) Утром буду рад пообщаться)

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

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

Дело не в количестве как таковом

А в ответственности

да ладно чувак, я же набросил просто

Вполне возможна сущность (заметьте я не говорю класс) с овер 100500 свойствами, при этом не наругаящая SRP и иже с ними

Ты хорошо наьросил

Есть частое заблуждение, что увеличение количества данных автоматически несет за собой нарушение зон ответственности

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

да, более чем. Но это не значит что не найдется кандидатов на слияние - тут уже на связанность надо смотреть.

И да так часто бывает

Есть частое заблуждение, что увеличение количества данных автоматически несет за собой нарушение зон ответственности

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

я тут вчера зашел в канал, а вы реально тут всегда обсуждаете как надо объекты разделять? интересн прост

какие у вас тут самые популярные темы

это я все пытаюсь популярно объснить что не так с геттерами, сеттерами и инкапсуляцией

я тут вчера зашел в канал, а вы реально тут всегда обсуждаете как надо объекты разделять? интересн прост

да, важная ж тема...

да, важная ж тема...

сколько бойцов уже пало на поле брани?

это я все пытаюсь популярно объснить что не так с геттерами, сеттерами и инкапсуляцией

всеж понятно, сеттеры не нужны

Имхо это невозможно сформулировать. Максимум ты получишь f = c (1/n). Где "C" некоторый коеффициент значительно плавающий от проекта к проекту. И "N" количественная связность компонентов проекта. Не могу объяснить четко. Надо при встрече...

я тут вчера зашел в канал, а вы реально тут всегда обсуждаете как надо объекты разделять? интересн прост

Да не

я тут вчера зашел в канал, а вы реально тут всегда обсуждаете как надо объекты разделять? интересн прост

Обычно обсуждаем идеальные пропорции джина к мартини в "Веспер"

всеж понятно, сеттеры не нужны

ну вот а народ думает что сеттеры и дают ту самую инкапсуляцию.... а потом орут что юнит тесты придумали мудаки потому что они постоянно ломаются

ну и код нипонятный

ну вот а народ думает что сеттеры и дают ту самую инкапсуляцию.... а потом орут что юнит тесты придумали мудаки потому что они постоянно ломаются

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

типа в метод что-то передаешь и кажется там чет по особому происходит, а не просто присвоение какое-то

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

это понятно, вопрос как показать что нифига не проще а мозг тебя обманывает)

а, ты про "без сеттеров"

))))

народу проще мыслить категориями процедуры и стэйт

пока не доходит до чтение этого кода

https://gist.github.com/zloyuser/e3bf2550bb1016385e1e1b65d7b74886

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

максимум обновлять результат внутри

Вот вам чуточки Элексира на пэхапе

ну вот а народ думает что сеттеры и дают ту самую инкапсуляцию.... а потом орут что юнит тесты придумали мудаки потому что они постоянно ломаются

Решил Егора переплюнуть?)

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

https://gist.github.com/zloyuser/e3bf2550bb1016385e1e1b65d7b74886

Емае

Первый раз вижу что так можно писать ?

Решил Егора переплюнуть?)

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

Генераторы крутая штука

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

Но идея та же?

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

Если он не меняет стейт он не нужен. Ибо видимо это другая модель... CQRS головного мозга все дела...

Если он не меняет стейт он не нужен. Ибо видимо это другая модель... CQRS головного мозга все дела...

свойство это то же обращение к паблик полю

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

только с примочками

если хочешь менять стейт методы в помощь

Первый раз вижу что так можно писать ?

Это неограниченное поле экспериментов. Присоединяемся :)

Это неограниченное поле экспериментов. Присоединяемся :)

Я после дарта не смогу накинуть на пыхе, извиняй :(

Та оно то пофигу на чем. Абы генераторы были...

Та оно то пофигу на чем. Абы генераторы были...

Прям на главной странице языка)

Правда, они для другого там, но не суть

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

Я ж надеюсь меня не убьют здесь за код не на пхп? ?

Я ж надеюсь меня не убьют здесь за код не на пхп? ?

я на шарпе пишу

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

Ммм... квантовое?

Ммм... квантовое?

ВОТ ИМЕННО!

квантовое ООП, непонятное и беспощадное

новый термин

Точно!

когда зритель влияет на состояние

))))

Предлагаю форсить

+

Заходит?

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

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

Ну он попросил генераторы :с

а)

Но ссылку, пожалуй, удалю

Заходит?

Перерос. Но пример хороший.

Перерос. Но пример хороший.

Если быть честным, я не видел использование их еще

В какой-нибудь либе популярной

А в пыхе так и подавно не видел

Копни глубже

Их вроде сделали, вроде удобно, но никто не юзает

Ети ваши async / await всего лишь сахар над генераторами

Ну лан это жирно... конечно там куча нюансов: таймеры, стримы и иже с ними

Но по факту да

Я ж и не спорю)

https://github.com/dart-lang/sdk/tree/master/sdk/lib/async