#functional_objects

В прошлый раз мы смотрели, как изолировать часть логики. Сегодня же поговорим о ситуации, когда у изолированной логики есть сложные для тестирования или контроля части.
Возможно, вы слышали о таком подходе, и сегодняшняя тема вызывает ассоциацию с миром javaEE, но поверьте, это знание выручает меня каждый день. Начнем с примеров.

Спасибо всем за вопросы! Приятно видеть ваш интерес к постам. Надеюсь, что в будущем фидбека будет еще больше :)

> Привет! Вижу, ты часто пишешь про Dependency Inversion, и поэтому хотел бы спросить: в чем для тебя принципиальная разница между di и паттерном strategy? Спрашиваю, т.к., на мой взгляд, разница между определениями в Ruby несколько размыта.

Мне нравится ответ SO на такой же вопрос.

Если в двух словах — strategy и DI работают одинаково. Однако различия тоже есть. В случае с DI изменение зависимости во время работы программы — редкий случай. Например, если используете DI с hanami экшенами, то в экшен пробрасывается интерактор или репозиторий. Вероятность того, что в рантайме экшен будет использовать другой репозиторий или интерактор, крайне мала.

В случае паттерна strategy вероятность передачи разных объектов выше. Например, использование разных форматов данных (http, pdf, xml, etc) в одном рантайме.

> А как ты для себя решаешь, когда использовать service object, а когда interactor?

Функциональные…