Pull to refresh

Comments 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
Only those users with full accounts are able to leave comments. Log in, please.