@kanaflow

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

Привет всем, пара вопросов по закону Деметры) 1. Он про сокрытие структуры, т.е. про то как правильно готовить инкапсуляцию?) 2. Сокрытие данных - это НЕ про инкапсуляцию, а про грамотное расширение объекта, т.е. про Open-Close принцип, по сути?

Привет всем, пара вопросов по закону Деметры) 1. Он про сокрытие структуры, т.е. про то как правильно готовить инкапсуляцию?) 2. Сокрытие данных - это НЕ про инкапсуляцию, а про грамотное расширение объекта, т.е. про Open-Close принцип, по сути?

information expert

и да инкапсуляция не только про information hidding

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

да,прости, ты прав

Привет всем, пара вопросов по закону Деметры) 1. Он про сокрытие структуры, т.е. про то как правильно готовить инкапсуляцию?) 2. Сокрытие данных - это НЕ про инкапсуляцию, а про грамотное расширение объекта, т.е. про Open-Close принцип, по сути?

с пунктом 2 не согласен

данные можно скрывать и без соблюдения OCP

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

Привет всем, пара вопросов по закону Деметры) 1. Он про сокрытие структуры, т.е. про то как правильно готовить инкапсуляцию?) 2. Сокрытие данных - это НЕ про инкапсуляцию, а про грамотное расширение объекта, т.е. про Open-Close принцип, по сути?

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

Инкапсуляция это лишь один из способов достижения сокрытия инф.

Привет всем, пара вопросов по закону Деметры) 1. Он про сокрытие структуры, т.е. про то как правильно готовить инкапсуляцию?) 2. Сокрытие данных - это НЕ про инкапсуляцию, а про грамотное расширение объекта, т.е. про Open-Close принцип, по сути?

закон деметры про сокрытие информации

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

open/close = protected variations = information hiding

есть заметка Алистера кокберна (вроде его) где он делился что когда выдумывал protected variations из grasp он просто не знал про open/close и в целом это одно и то же и суть information hiding

закон деметры это не совсем про сокрытие, это про упрощение модулей

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

Но по каким критериям ты ограничиваешь знания модуля о других модулях?

мне всегда казалось что LoD это следствие information hiding.

в самом законе не упоминается методология)

тут уже здравый смысл работает

"don't talk to strangers". и пример про собаку и ее лапы

то есть как по мне LoD это хороший способ трекать недостатки в сокрытии информации

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

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

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

мы может по разному information hiding трактуем?)

что значит "просто скрывать"?)

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

скрыл - потерял модуль

Оооо..спасибо, парни) будет над чем подумать

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

ну.... надо обдумать. Я с тобой не согласен (не могу придумать как можно получить солнышко если у тебя с IH все хорошо) да и примеры к LoD намекают больше про IH... но ладно, вернемся к разговору на следующей неделе)

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

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

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

ивенты снижают связанность. Это так. Но не забывай про coheasion.

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

+ есть возможность трекать что в какой последовательности происходит

и это не влияет на консистентность

угу, расскажи это проекту DST

ивенты снижают связанность. Это так. Но не забывай про coheasion.

cohesion = связность, не?

угу, расскажи это проекту DST

там была проблема с кохижен, разделением ответственности, дублированием логики, и вообще мы там нехило так наговнокодили с тобой)

cohesion = связность, не?

а coupling тогда что?)

а ну да, кохижен - связность, кауплинг - связанность

или внутренняя и внешняя связанонсть модуля

там была проблема с кохижен, разделением ответственности, дублированием логики, и вообще мы там нехило так наговнокодили с тобой)

ай не пизди. Я туда пришел когда там был уже полный пиздец ты :)

ай не пизди. Я туда пришел когда там был уже полный пиздец ты :)

я там только редактор презентаций пилил) вини во всем другого Сергея

ну и да, мы потом знатно айдишки переделывали)

да... может быть и такое

но это мы уже вместе делали если ты помнишь)

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

модули - это что угодно, куски приложения

модули - это что угодно, куски приложения

я понимаю) так их и трактую

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

акторы там

ну да, и ивенты между модулями побольше - норм тема

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

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

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

один знает о другом, второй о первом может и не знать. Он тупо ивент кидает.

ему не важно будет кто его обрабатывать или нет

а потому прямой зависимости нет. Это просто часть его контракта

кинуть ивент

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

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

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

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

(доменные ивенты типа))

но на определенном масштабе да, надо будет знать о диспетчере

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

короч хз о чеммы если честно

мне ивенты нравятся)

ивенты - это магия

с одной стороны все хорошо, бросил и забыл

ивенты - это магия

никакой магии

коуплинг и кохижн победил

в смысле никакой? а консистентность кто будет делать?

ивенты - это магия

вызовы методов тогда тоже магия)

в смысле никакой? а консистентность кто будет делать?

> Любая достаточно развитая технология неотличима от магии.

в смысле никакой? а консистентность кто будет делать?

экторы?)

вызовы методов - это вызовы методов конкретного обьекта, ты про него знаешь и контролируешь

а ивенты - это бросил и забыл

про ивент ты знаешь столько же)

вызовы методов - это вызовы методов конкретного обьекта, ты про него знаешь и контролируешь

ну вызвал ты явно метод другого модуля - кто тебе тут будет консистентность гарантировать?

если это мой модуль - то я

а ивенты - это бросил и забыл

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

если это мой модуль - то я

с ивентами также

если это мой модуль - то я

а если не твой - то и не твои проблемы

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

решаем ивентами ;)

ивенты имеют отношения к решению задачи столько же, сколько и вызовы методов

тут проблема не в ивентах, а в работе с внешними источниками

методы - все твои

нене, если ты вызываешь метод, ты его вызываешь у кого-то конкретного

ты контролируешь вызов каждого метода

А некоторые заявляют, что с «этими событиями не разберешься, что и где вызывается и как обрабатывается».

а если ты послал ивент в диспетчер, то ты не знаешь что с ним дальше происходит

нене, если ты вызываешь метод, ты его вызываешь у кого-то конкретного

у объекта непонятно как заимплеменченного? Оч ценное знание конечно

Поэтому типа ну их нах