Комментарии 6
Тут важно достичь выразительности, чтобы читая код был понятен процесс, который он выражает. Степень выразительности лучше определить внутри команды. Но я бы тоже вынес многострочку в отдельный метод -) Возможно в Сервисный слой.
Для меня это противоположность Ubiquotous Language в DDD
class DrivingStart < LunaPark::Interactors::Sequence
def call!
Service::CheckEngine.call
Service::StartUpTheIgnition.call car, with: key
Service::ChangeGear.call car.gear_box, to: :drive
Service::StepOnTheGas.call car.pedals[:right]
end
end
В моей мысленной картине мира двигатель часть машины и никаких сервисов нет и я думаю как-то так:
car.engine.check
car.ignintion.startUp with:key
car.gear.change to: :drive
car.pedals.gas.press
Вопрос — зачем эти прослойки?
Вернее
сервис ответов на вопросы:: задать вопрос.сказать
сервис ответов на вопросы:: зачем.сказать
сервис ответов на вопросы:: эти.сказать
сервис ответов на вопросы:: прослойки.сказать
Services::
и Interactors::
— это лишняя абстракция, опытным разработчикам она не нужна. Я использую ее, здесь, в статьях и мы используем в части проектов, для наглядности, чтобы показать к какому шаблону проектирования относится CheckEngine
. Об этом я упомянул в последней части статьи.
.
pedals.gas.press
— это один из возможных вариантов если он удовлетворяет вашу команду, используйте его. Мне, лично, не нравится в этом подходе, что метод относится к субъекту, а не к объекту. Дрова — нарубитесь, хлеб нарежься, масло намажься.
Если у нас подходящий домен, можно сделать:
racer.press car.pedals.gas
Но это только в подходящем домене. Машина для гонщика и машина для инженера обслуживания, это две разные модели одной и той же реальной сущности.
что метод относится к субъекту, а не к объекту.
Субъект — это тот, кто делает, объект — это тот над чем делают. Так как pedals это то, чем делают и объект на на нем, то метод относится у меня к объекту, а у вас к субъекту.
Машина для гонщика и машина для инженера обслуживания, это две разные модели одной и той же реальной сущности.
Interface segregation principle?
Да, извиняюсь, перепутал значения терминов субъект и объект.
Да, Interface segregation principle, была статья как-раз неплохая на эту тему
https://medium.com/roonyx/solid-ruby-ad046727ec26
И там как раз пример приводится:
class Driver
def drive
@car.open
@car.start_engine
end
end
Но если бы у нас была сущность Human, то я бы не стал вносить метод drive
в нее:
module Entities
class Human
# ...
end
end
module Services
#не все мы водим машины, и лучше это вынести в отдельный сервис
module HandlingVehicle
def self.drive(racer, car)
# ...
end
end
end
Поваренная книга разработчика: DDD-рецепты (5-я часть, Процессы)