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

ну-ну

в зависимости от контекста и говнокод сладок, я знаю

Максимализм и поиск серебряной пули... ну-ну

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

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

не сотвори себе кумира, как говорится...

Нужно и то, и то. Да, возможно, with* используется чаще. Хороший пример для without был с findWithoutAdminPriviliges

Хотя в пример с find* я бы вообще использовал спецификацию.

Нужно и то, и то. Да, возможно, with* используется чаще. Хороший пример для without был с findWithoutAdminPriviliges

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

Хотя в пример с find* я бы вообще использовал спецификацию.

find(WithoutAdminPriviliges(id))

с этой точки зрения разницы немного

с этой точки зрения разницы немного

Согласен

осталось обьяснить девеловерам, поему нарушать SRP это плохо...

самая сложная часть

:)

осталось обьяснить девеловерам, поему нарушать SRP это плохо...

Ничего плохого

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

ладно слишком жирно

Где связь между srp и кол-вом файлов?)

И где связь между кол-вом файлов и удобством)

Где связь между srp и кол-вом файлов?)

!srp = меньше классов = меньше файлов))

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

!srp = меньше классов = меньше файлов))

Чет я даже хз что ответить...) ты прав, толсто слишком)

И где связь между кол-вом файлов и удобством)

ну ты не ловил никогда себя на мысли что очень часто между файлами перключаешься?) а так колесом промотал куда надо, и готово! + копипастить легче в рамках одного файла

ну ты не ловил никогда себя на мысли что очень часто между файлами перключаешься?) а так колесом промотал куда надо, и готово! + копипастить легче в рамках одного файла

Да нет) чет никогда не парило)

!srp = меньше классов = меньше файлов))

не факт

вообще никакой корреляции

я могу тебе сделать любой вариант декомпозиции. Много файлов, много классов - мало SRP, мало классов и мало файлов и много SRP

SRP про выделение ролей, кому предназначен функционал и кто может захотеть его менять

оно не про то что бы делать классы в 10 строк

словом... SRP не выражается напрямую в количестве кода. Количество кода МОЖЕТ быть симптомом нарушения SRP но может и не быть)

Но если у тебя 1 класс на проект, то 100% же что то не так?)

Но если у тебя 1 класс на проект, то 100% же что то не так?)

читай про кохижен)

всем трям! существует ли чтиво на русском языке после прочтения которого я стану экспертом в области акторов и всяких там ролей? желательно в очень сжатом формате и с понятными примерами...?

Без смс и регистрации?)

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

естстн

На русском, вряд ли) на нем ги сиотреть, ни читать особо нечего) посмотри в описании группы. Там много всякого собрано

я вообще не понял чем они от ивентов отличается...

srp это про то, чтобы класс имел только одно поведение?)0

чтоб рулил одним процессом

srp это про то, чтобы класс имел только одно поведение?)0

Одну причину для изменения

Одну причину для изменения

изменения класса? ocp говорит не изменять класс, как жи сложна(9

изменения класса? ocp говорит не изменять класс, как жи сложна(9

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

как то я хервоо сказал

Короче если меняется какая то логика, для исполнения которой класс создавался, то код можно менять(но причина для этого должна быть одна, в рамках выделеннйо ответственности). А если ты хочешь изенить какие-то детали реализации этой логики, то должен был предусмотерть точки расширения для этого. Самый простой пример отправка уведомления. У тебя есть сервис который проверяет что пользователь должник и отсылает ему уведомление например Емайлом. Если у тебя меняется определение того что считать должником, и ты полез менять код - этонорм. А вот если поменялось метод отправления с емайла на смс, и тебе пришлось лезть в код то это хреново, т.к должно меняться с помощью передачи нужного объекта отправителя.

Артур, пздц ты сложно глаголишь

Хотя бля определение кто такой должник тоже можно вынести в интерфейс DebtorDetectorStrategy и подсовывать ее реализации в класс проверяльщика

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

Теперь все ясно, пасиба

Теперь все ясно, пасиба

Ты ж ничо не понял

Ты ж ничо не понял

Ну здесь ясно все, а ты ток "забей" отвечаешь

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

кстате, это неправда

в OCP нет ничего про "код класса"

в OCP нет ничего про "код класса"

Да я соглассен. Но это прискреб к словам) ну и я потом сразу же признал что хуево сформулировал

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

то есть, он "открытый"

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

ну и типа интерфейсы ты "закрыл" (на самом деле "closed"- стоит переводить как "замкнул", для точности) , но можешь расширять всякими композиционными способами

всем трям! существует ли чтиво на русском языке после прочтения которого я стану экспертом в области акторов и всяких там ролей? желательно в очень сжатом формате и с понятными примерами...?

Изучай эрланг во имя добра https://github.com/mpyrozhok/learnyousomeerlang_ru/blob/master/pdf/learnyousomeerlang_ru.pdf

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

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

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

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

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

Он достаточно приятен как мне показалось, сразу понятно что возвращается и какие инварианты у функции есть, паттернматчинг из коробки, акторы посылка и прием сообщений. А что не так с его синтаксисом?

книжка годная?

и свежая?)

А эрланг не перетек в эликсир?

вроде ещё отдельно @clever_cat?)

Если что я не специалист. Элексир отдельный язык на базе виртуальной машины эрланга. Книга 3 х годичной давности. Мне понравилась. Все концепции объясняются доступно и просто.

а есть правильное название у архитектуры с акторами?

я так и не смог по эрланг открыть.. я пока только на планшете,так он не открывает именно этот пдф

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

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

можешь почитать оригинальную публикацию на эту тему)

https://en.wikipedia.org/wiki/History_of_the_Actor_model

можешь с этого начать

там куча отсылок на публикации

изучение идей стоит все же начинать с первоисточников

хотя бы мельком по ним пробежаться

там и идея обоснована. и описана...

всетаки модель акторов..

и без привязки к ЯП

я так и не смог по эрланг открыть.. я пока только на планшете,так он не открывает именно этот пдф

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

всетаки модель акторов..

да, ты можешь воспринимать все эти SOA и микросервисы как развитие этих идей. Что есть у тебя какие-то "штуки" которые "обмениваются сообщениями" и "не делят данные между собой"

ну ты не ловил никогда себя на мысли что очень часто между файлами перключаешься?) а так колесом промотал куда надо, и готово! + копипастить легче в рамках одного файла

Полегче, храждане, вас же дети услышать могут ?

по поводу архитектуры - архитектура это всегда наличие ограничений, которые призваны дать какую-то характеристику. Гексагональная архитектура - про направление зависимостей и инверсию зависимости. Это дает тебе гибкость в плане изоляции бизнес правил от инфраструктуры. Если тебе это надо - можешь туда смотреть. Если тебе надо организовать какую-то децентрализацию - можно другие ограничения рассматривать. Ну и т.д. Если мы попробуем выстроить аналогию между знакомыми тебе ООП штуками и экторами.... представь себе систему, простенькую... есть объект представляющий какую-то сущность. Например сделаем простенький todo список. В языках типа Java и в целом наследующих объектную модель всяких там симмул и C++, у тебя будут объекты на каждый список, будут объекты для каждого элемента списка и ты будешь работать как бы с ними. Будешь просить добавить новую тудушку в список, можешь просить "Завершить" конкретный элемент списка и т.д. В этом примере "объект" является не более чем границей зоны ответственности на уровне рантайма. То есть у тебя есть "внутри" и "снаружи", есть другие объекты с которыми нам надо взаимодействовать. В языках типа Erlang за "границы" отвечают микротреды. То есть это такие вот штуки на уровне рантайма которые позволяют тебе изолировать состояние. На каждый список будет тред, который отвечает только за список. Для работы отдельными элементами и их деталями мы можем сделать свои треды.... по треду на каждый агрегат (штуки учавствующие в бизнес транзакции). Ну и все это обменивается сообщениями. Теперь важный момент отличающий "вызов метода объекта" от "отправки сообщений" - наличие мэйлбоксов. То есть наш "эктор" отправляет сообщение другому, и все сообщения являются асинхронными по своей природе. Отправил сообщение и все. Положил его в мэйлбокс эктору а эктор как освободится почитает. Он может тебе прислать какой-то результат и положить уже в мэйлбокс первого эктора и т.д. Это решает вопрос синхронизации действий. Ну и так как "общих данных между экторами нет" - нет необходимости хоть что-то лочить (мэйлбоксы можно тоже лок-фри сделать). У тебя в целом получается полностью неблокируемая система. Для телекомов это вообще было смертельно важно потому именно в этом контексте эрланг и развивался.

вот.... как-то так если кратенько суть....

по последнему абзацу... то есть методоа у акторов нет? двухсторонние сообщения?

по последнему абзацу... то есть методоа у акторов нет? двухсторонние сообщения?

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

как ты понимаешь - все упирается как раз таки в рантайм который все это разруливает. В языках типа java/scala для этого нужны жуткие вещи вроде akka, а для эрланг это все есть на уровне виртуальной машины самого языка, родная фича для платформы.

https://arxiv.org/vc/arxiv/papers/1008/1008.1459v8.pdf

можешь еще вот с этой публикацией ознакомиться