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

Атомарной можно считать чистую абстрактную функцию

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

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

я на самом деле сам в нем на 100% не уверен, но всё же

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

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

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

но это за скоупом этого разговора я думаю

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

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

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

на функциональщину перешёл или есперимент такой? не боишься что уколит в итоге?

на функциональщину перешёл или есперимент такой? не боишься что уколит в итоге?

не, ооп не нужно просто, что бы код писать

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

не, ооп не нужно просто, что бы код писать

всё ещё не понимаю

но не в бизнес логике

просто процедурно всё делаешь или как?

ну, я функциональные объекты использую и все

т.е. по сути у меня все через функции в функциях

и ооп в персистенс уровне и энтити

proc / lambda

Так чтоли?)

ну, можно просто class Something def call(payload) end end

а в чем профит

ну, можно просто class Something def call(payload) end end

блин я считай так же

в том, что изолированные объекты, которые по сути функции

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

и они что то делают

остальное всё приватное

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

ну сервисы да, #perform

ну и в тестах вместо объекта можно прок/лямбду прокинуть можно

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

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

я вот почему то решил что у меня джобы это перформ

ну и я сам склоняюсь к тому что иммутабельное лучше

а сервисы это колл

но не всегда возможное

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

так я и не говорил, что имутабельность != ооп

ну и я сам склоняюсь к тому что иммутабельное лучше

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

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

Из за многопоточности?

так я и не говорил, что имутабельность != ооп

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

Из за многопоточности?

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

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

ну потому что это не ооп, это полумикс фп и ооп

ооп, вдохновлённое фп?

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

т.е. это что-то в духе SERVICE = Service.new(deps) SERVICE.call(payload) SERVICE.call(payload) SERVICE.call(payload)

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

используются треды сайдкика например?

да

ооп, вдохновлённое фп?

скорее наоборот

это реал не ооп

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

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

>чистый ооп не работает не верю

читали его статьи?

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

this

конечно

>чистый ооп не работает не верю

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

ну в общем именно он поменял мое мышление об ооп и всем таком

открыл глаза так сказатб

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

)

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

ну и как пример, вот кусок кода, это не ооп и не фп, это какая-то каша https://github.com/davydovanton/cookie_box/blob/master/lib/decks/operations/create.rb#L16-L19

типа блин иногда читаешь его

и вроед те вещи к которым привык он обсирает

и ты такой типа

блин а ведь он прав

хелперы это не ооп

какого хуя

++

ERROR: S client not available

хелперы это не ооп

это модули, а модули это не ооп

геттеры и сеттеры инкапсуляцию нарушают

пиздец

и место женщины на кухне!

))

ну это шутка конечно же он не это совсем имел ввиду

я уже не помню чтобы он такое говорил

я уже не помню чтобы он такое говорил

в секреты бэкенда было

т.е. это что-то в духе SERVICE = Service.new(deps) SERVICE.call(payload) SERVICE.call(payload) SERVICE.call(payload)

а почему не создается каждый раз экземпляр класса? SERVICE.new(deps).call(payload) SERVICE.new(deps)..call(payload) SERVICE.new(deps).call(payload) Чем оправдан твой подход переиспользовать экземпляр несколько раз? учитывая что появляется потенциальная проблема мутабельности стейта

собсно там я с ним и познакомился

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

а почему не создается каждый раз экземпляр класса? SERVICE.new(deps).call(payload) SERVICE.new(deps)..call(payload) SERVICE.new(deps).call(payload) Чем оправдан твой подход переиспользовать экземпляр несколько раз? учитывая что появляется потенциальная проблема мутабельности стейта

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

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

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

+++

зато давно не видел проблем в духе “бля, у меня тут поменялось что-то но я хз где и что"

или "у меня тут в дев все норм, а в проде почемуто перетирается"

не, такого тоже нет

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

+ эту ошибку дурака не обойти ибо все просто развалится

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

ну и как пример, вот кусок кода, это не ооп и не фп, это какая-то каша https://github.com/davydovanton/cookie_box/blob/master/lib/decks/operations/create.rb#L16-L19

а ты Create тоже инитишь один раз? какие зависимости в нее передаешь?

а ты Create тоже инитишь один раз? какие зависимости в нее передаешь?

ага

вот все зависимости https://github.com/davydovanton/cookie_box/blob/master/lib/decks/operations/create.rb#L8

репозиторий для работы с данными + слаг генератор

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

если честно так и не понял что такое слаг

вот все зависимости https://github.com/davydovanton/cookie_box/blob/master/lib/decks/operations/create.rb#L8

а в каком месте происзодит create=Create.new(params) ? как я понял у тебя такой подход

если честно так и не понял что такое слаг

https://en.wikipedia.org/wiki/Clean_URL#Slug

а в каком месте происзодит create=Create.new(params) ? как я понял у тебя такой подход

у меня IoC контейнер используется. на старте приложения он регестрирует все зависисмости с их зависимостями и собирается

если что-то не то идет, то все упадет на момент старта

ну то что это хьюман ридабл название чего то