или стейт буду передавать в качестве аргумента

ой все

если ты про query методы которые чето там считают и возвращают - это не "доступ к стэйту"

или стейт буду передавать в качестве аргумента

вот это норм

не важно про что я, бахнул свойств пачку, передал ссылку на объект, зачекал свойства

получил водокачку

Просто если всё на полях приватных делать (вообще без геттеров-сеттеров) - то тут вопрос рефакторинга остро встаёт. Потому что для десериалищации объекта из базы - надо строками указывать имена полей. То есть переименовал поле - будь добр не забыть и конфиг сущности в ORM’ке поправить.

но в целом есть много вариантов. С тем же временем мне понравилась идея воспринимать время как стрим тэймстэмпов

получил водокачку

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

если ты про query методы которые чето там считают и возвращают - это не "доступ к стэйту"

Не, кверики вообще со своими моделями

И со своей микро-орм

Не, кверики вообще со своими моделями

не путай теплое и мягкое (CQS и CQRS)

Просто если всё на полях приватных делать (вообще без геттеров-сеттеров) - то тут вопрос рефакторинга остро встаёт. Потому что для десериалищации объекта из базы - надо строками указывать имена полей. То есть переименовал поле - будь добр не забыть и конфиг сущности в ORM’ке поправить.

Гетеры сетеры никак не решают проблему же?

разные масштабы

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

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

Гетеры сетеры никак не решают проблему же?

Публичный геттер и приватный сеттер решают

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

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

есть кейсы когда все нормально, но это далеко не все кейсы. Шаринг стэйта (а это именно это и есть) - самый главный источник проблем с декомпозицией.

И все фишки, типа переименования свойства начинают работать.

Попутно меняя и лямбду в конфиге ОРМ, если ты сущность рефакторишь

Публичный геттер и приватный сеттер решают

геттеры то зачем?)

есть кейсы когда все нормально, но это далеко не все кейсы. Шаринг стэйта (а это именно это и есть) - самый главный источник проблем с декомпозицией.

ну короче у тебя шмотка в рюкзаке, у неё всякие параметры есть, какой аргумент себе возьмешь, какой другу отдашь?

ну короче у тебя шмотка в рюкзаке, у неё всякие параметры есть, какой аргумент себе возьмешь, какой другу отдашь?

неверная метафора

а хотя.... объяснение стэйта как "просто все подряд запихнутое в рюкзак" очень точно отражает то как люди делают декомпозицию

а хотя.... объяснение стэйта как "просто все подряд запихнутое в рюкзак" очень точно отражает то как люди делают декомпозицию

я щя не про стейт

а про шмотку

у тя шмотка

Публичный геттер и приватный сеттер решают

как? Хранить орм-специфичные методы, которые никому на самом деле не нужны?

у тя шмотка

тогда я не понял вопроса

и со старыми именами, которые уже неактуальны

геттеры то зачем?)

config.Property(x=> x.Name).Required().HasMaxLength(200); Вот Name - это свойство с публичным геттером. А если его нет, а есть только поле, то config.Property(”_name”).Required().HasMaxLength(200);

config.Property(x=> x.Name).Required().HasMaxLength(200); Вот Name - это свойство с публичным геттером. А если его нет, а есть только поле, то config.Property(”_name”).Required().HasMaxLength(200);

нифига не понимаю...

попахивает смешением ответственности

тогда я не понял вопроса

ну у шмотки свойства, ты её передаешь куда надо, обращаешься к чему хочешь, ты же не фреймворк пишешь! Что такого что о шмотке весь проект будет знать и какие у неё свойства, если это неотъемлемая часть проекта

нифига не понимаю...

Во втором случае - у тебя в конфиге - строка

зачем задрачиваться ради задрачивания

а потом бить в грудь себя и кричать я ЖЕЖ ООП

зачем задрачиваться ради задрачивания

не ради задрачивания, если ты не понимаешь преимуществ (и не пытаешься разобраться) - то это твои проблемы))))

ну у шмотки свойства, ты её передаешь куда надо, обращаешься к чему хочешь, ты же не фреймворк пишешь! Что такого что о шмотке весь проект будет знать и какие у неё свойства, если это неотъемлемая часть проекта

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

я ж к этому всему пришел не потому что "скучно было" а потому что хлебнул проблем с изменениями требований

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

сорри я про игру, вещь из инвентаря

сорри я про игру, вещь из инвентаря

ну вот пасхальный спешиал какой. Яйца там или кролики

ну вот пасхальный спешиал какой. Яйца там или кролики

дальше?) продолжай

нифига не понимаю...

В первом случае, я иду в класс User, становлюсь на имя свойства с геттером, жму Ctrl+R+R, пишу UserName, и мой конфиг из config.Property(x=> x.Name).Required().HasMaxLength(200); превращается в config.Property(x=> x.UserName).Required().HasMaxLength(200); , а во втором он каким был - таким и остался, и мне надо ручками идти и править его.

В первом случае, я иду в класс User, становлюсь на имя свойства с геттером, жму Ctrl+R+R, пишу UserName, и мой конфиг из config.Property(x=> x.Name).Required().HasMaxLength(200); превращается в config.Property(x=> x.UserName).Required().HasMaxLength(200); , а во втором он каким был - таким и остался, и мне надо ручками идти и править его.

не вижу профита

но в целом есть много вариантов. С тем же временем мне понравилась идея воспринимать время как стрим тэймстэмпов

Время — это индексированная последовательность событий, это включает в себя события с таймстампами как разновидность

А когда там в свойствах ссылки на другие сущности - VO - то вообще трэш угар и веселуха начинается

Время — это индексированная последовательность событий, это включает в себя события с таймстампами как разновидность

спасибо кэп

Ну я бы не сказал что это очевидно

А когда там в свойствах ссылки на другие сущности - VO - то вообще трэш угар и веселуха начинается

то есть ты валидируешь сущность извне?

ясно, свойства не нужны, методы тоже

В первом случае, я иду в класс User, становлюсь на имя свойства с геттером, жму Ctrl+R+R, пишу UserName, и мой конфиг из config.Property(x=> x.Name).Required().HasMaxLength(200); превращается в config.Property(x=> x.UserName).Required().HasMaxLength(200); , а во втором он каким был - таким и остался, и мне надо ручками идти и править его.

ide-проблемы

не вижу профита

Профит в том, что у тебя не возникнет ситуации, когда в модели у тебя одно, а в конфиге ORM другое.

ну вот пасхальный спешиал какой. Яйца там или кролики

продолжай, интересно же

ide-проблемы

То есть она должна имя приватного поля сама туда запихнуть по-твоему?

продолжай, интересно же

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

и надо везде добавлять проверочки

Профит в том, что у тебя не возникнет ситуации, когда в модели у тебя одно, а в конфиге ORM другое.

потому лучше запихнуть код занимающийся конфигурацией ORM в сущность?

то есть ты валидируешь сущность извне?

Нет, это конфиг ORM, то, как твоя сущность ляжет на базу.

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

всмысле? какой новый тип шмотки

То есть она должна имя приватного поля сама туда запихнуть по-твоему?

да, это статически анализируемо

потому лучше запихнуть код занимающийся конфигурацией ORM в сущность?

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

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

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

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

хз, сойдемся на том что это "компромис" и успокоимся))

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

я не догдал суть того что ты вещаешь и причем тут геттеры

я не догдал суть того что ты вещаешь и причем тут геттеры

ну просто к челу там докалупались, я написал про геттеры

если мы говорим про инвентар в играх - ты когда "достаешь" предметы то меняется стэйт

хз, сойдемся на том что это "компромис" и успокоимся))

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

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

а знать о геттерах типа сакс

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

давай разберемся с логической цепочкой.... ты сделал приватными сеттерами потому что публичные сеттеры тебе не нужны. Да и в целом сеттеры тебе нужны только для ORM. Геттеры так же только для ORM. Появилось это решение как следствие какой-то другой проблемы (то что у тебя там что-то в отдельном проекте и по другому тяжело и больно). Скорее всего у этой проблемы найдется и другое решение которое не подразумевает наличия ни геттеров ни сеттеров, но в целом я допускаю что "на данный момент сойдет если использование этих геттеров и сеттеров строго ограничено конкретно этой задачей и никто и никогда не будет юзать эти геттеры для других целей"

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

шарить стэйт сакс, геттеры часто для этого юзаются, но не всегда. Потому и я и Олег говорим о том что геттеры плохо или хорошо зависит от контекста их использования. Твой же пример не про геттеры - так как подразумевается изменение стэйта (то самое квантовое ООП, либо просто данность о том что не все можно сделать соблюдая CQS)

шарить стэйт сакс, геттеры часто для этого юзаются, но не всегда. Потому и я и Олег говорим о том что геттеры плохо или хорошо зависит от контекста их использования. Твой же пример не про геттеры - так как подразумевается изменение стэйта (то самое квантовое ООП, либо просто данность о том что не все можно сделать соблюдая CQS)

эм? всмысле подразумевается изменение стейта?

стейт только через методы

эм? всмысле подразумевается изменение стейта?

ты когда достаешь что-то из рюкзака - ты меняешь стэйт рюкзака.

давай разберемся с логической цепочкой.... ты сделал приватными сеттерами потому что публичные сеттеры тебе не нужны. Да и в целом сеттеры тебе нужны только для ORM. Геттеры так же только для ORM. Появилось это решение как следствие какой-то другой проблемы (то что у тебя там что-то в отдельном проекте и по другому тяжело и больно). Скорее всего у этой проблемы найдется и другое решение которое не подразумевает наличия ни геттеров ни сеттеров, но в целом я допускаю что "на данный момент сойдет если использование этих геттеров и сеттеров строго ограничено конкретно этой задачей и никто и никогда не будет юзать эти геттеры для других целей"

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

ты когда достаешь что-то из рюкзака - ты меняешь стэйт рюкзака.

не достаю, в просто обращаюсь к вещи в рюкзаке к примеру

не достаю, в просто обращаюсь к вещи в рюкзаке к примеру

и зачем ты к ней обращаешься?

internal - это видимость в пределах сборки

Среднее между public и private

и зачем ты к ней обращаешься?

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

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

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

и еще много как

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

Ок, понял тебя)

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

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

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

ну а в формулку с руки у вещи посчитать или с ноги

или проверить подойдет вещь что бы одеть или нет

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

ну а в формулку с руки у вещи посчитать или с ноги

мне сложно так как для меня игры это незнакомая предметная область)

или для крафта

ну так

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

закон деметры покури

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

))))

ну а в формулку с руки у вещи посчитать или с ноги

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

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

вещи тогда параметры передай, напиши под каждый такой кейс в ней метод

https://martinfowler.com/bliki/TellDontAsk.html

а потом все равно в компонентах обращайся к этой вещи

ну спс