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

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

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

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

и дальше из этого, как из конструктора лего, пилить логику. Можно это всё обрамить сёрвис обжектом, но не суть, подача не так важна

вот. а "паттерн" сёрвис обжект, как мне кажется, он говорит: "братан, возьми этот кусок логики (и обмажься им), и вынеси в отдельный класс (или модуль, но это ещё хуже), в СЕРВИС"

фух, я выговорился

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

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

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

мне например было бы

ну с ходу конкретный пример не могу дать

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

Так это рейлсвей обычный

может придумаю чуть позже

Так это рейлсвей обычный

И проблема тут глубже чем кажется

Так это рейлсвей обычный

>мельчайшая частица взаимодействия в этом "паттерне" – это сервис ?

и дальше из этого, как из конструктора лего, пилить логику. Можно это всё обрамить сёрвис обжектом, но не суть, подача не так важна

сложно поддерживаемый подход имхо. Вносит много зависимостей. Вот есть какой-то сервис обджект, в нем инкансулирован код конкретного бизнес процесса. Он изолирован и это хорошо. Нежели изменил в какой-то детальке код, в 10 местах все сломалось

>мельчайшая частица взаимодействия в этом "паттерне" – это сервис ?

Кидание говна под шкаф

сложно поддерживаемый подход имхо. Вносит много зависимостей. Вот есть какой-то сервис обджект, в нем инкансулирован код конкретного бизнес процесса. Он изолирован и это хорошо. Нежели изменил в какой-то детальке код, в 10 местах все сломалось

Так зачем писать такой переиспользуемый код?

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

сложно поддерживаемый подход имхо. Вносит много зависимостей. Вот есть какой-то сервис обджект, в нем инкансулирован код конкретного бизнес процесса. Он изолирован и это хорошо. Нежели изменил в какой-то детальке код, в 10 местах все сломалось

я думаю ты как-то путаешь coupling и инкапсуляцию

вернее можно сказать смешиваешь чтоли

сложно поддерживаемый подход имхо. Вносит много зависимостей. Вот есть какой-то сервис обджект, в нем инкансулирован код конкретного бизнес процесса. Он изолирован и это хорошо. Нежели изменил в какой-то детальке код, в 10 местах все сломалось

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

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

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

ну я ещё не пришёл к определённому мнению по этому поводу пока

Так зачем писать такой переиспользуемый код?

ну да, наверное частое переиспользование вносит coupling

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

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

хм

интересная мысль

ну то есть private def a(b) ... end

попробую сегодня посмотреть свои сервисы в которых есть

ну да, наверное частое переиспользование вносит coupling

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

и сделать чтоб без них

это скорее всего означает что класс 1) сложный 2) может быть разделён на меньшие сущности

ребят что думаете?

мне кажется в этом есть доля истины

ну это моя эвристика

да, мне тоже интересно было бы услышать что другие думают

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

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

не, я про обычный PORO

не, я про обычный PORO

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

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

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

а где ты хранишь атомарные классы бизнес-логики, на основе которых делаются сервис обджекты?

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

как решение из гема отличается от poro?

типа они же не могут знать какая у тебя бизнесслогика

ну в плане да они дают dsl

а где ты хранишь атомарные классы бизнес-логики, на основе которых делаются сервис обджекты?

ты хочешь сказать, что если эти классы можно увидеть, то это не изоляция логики?

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

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

ну понятно что можно реюзнуть те классы и всё такое

ну не реюзай тогда

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

ониж для того и атомарные

чтоб ими пользоваться

как решение из гема отличается от poro?

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

ну типа ну хз как бы да и как бы нет

ты хочешь сказать, что если эти классы можно увидеть, то это не изоляция логики?

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

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

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

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

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

нет, почему?

ну я не хочу, я говорю, что это говно

и антипаттерн

ну да, наверное частое переиспользование вносит coupling

Жду когда разочаруешься в паттернах и ООП (без агрессии и чего-то ещё)

ну я не верю в паттерны на самом деле

верю в антипаттерны

жду когда разочаруешься в жизни

ERROR: S client not available

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

Да это все фигня и просто сахар к

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

Вот тут не согласен

и верю в принципы ооп

Вот тут не согласен

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

типа методы с кэшированием

вот тогда скорее всего не атомарный

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

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

Да это все фигня и просто сахар к

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

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

и верю в принципы ооп

Уже год не пишу по принципам ооп, брат жив

нет, почему?

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

Уже год не пишу по принципам ооп, брат жив

а батя говорит, молоца, хорошо сделал?

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

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

а батя говорит, молоца, хорошо сделал?

Ага

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

пинком лида\архитекта

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

зависит от опыта, как в итоге получится

зависит от опыта, как в итоге получится

ну все вообще зависит от людей которые пилят продукт

idiot-proof процесс нельзя придумать

Уже год не пишу по принципам ооп, брат жив

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

потому что свойство идиотов в том, что они умеют обходить идиот-пруф процессы

Вот тут не согласен

контр-пример?

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

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

если атомарность - 1 строка, то да, не атомарный

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

можем принять что атомарный значит неделимый

можем принять что атомарный значит неделимый

так не делимый - субъективное значение

вероятно

вот пример user && (user.admin? || user.manager?) - делимая строка?

(плохой пример на самом деле)

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

да, плохой

смотри