Comments 11
Явный вызов return не нужен, плюс если используете новый синтаксис для хэшей, то используйте его везде:
Но в последнем примере в полной мере не избавились от повторений, можно было использовать duck typing и сделать еще компактней.
def complect_task
{
id: task.gid,
title: task.title,
ts: task.ts,
author: task.author_id,
holder: complect_holder
}
end
Но в последнем примере в полной мере не избавились от повторений, можно было использовать duck typing и сделать еще компактней.
module CommonOp
def common(item)
{
id: item.gid,
title: item.title,
ts: item.ts,
author: item.author_id
}
end
end
class Event < Operation
include CommonOp
def complect_goal
common(goal).merge holder: complect_goal_content_header
end
end
class Task < Operation
include CommonOp
def complect_task
common(task).merge holder: complect_holder
end
end
Метод common можно поднять в базовый класс, и использовать его изначально
Вы правы, сейчас поправлю под «старый» синтаксис. Насчет return, для себя я вынес следующее — если можно написать return, то лучше его написать, ошибок меньше будет.
enum в ruby:
ProtocolElementTypeName = [:task, :note, :event].freeze
ProtocolElementTypeName.include?(type) or fail
Ruby-метод для создания объекта нужного класса
def self.Complect type
const_get("Complect::#{type.capitalize}").new
rescue NameError
fail "Неизвестный тип"
end
module Complect
class Event; end
class QC; end
class Tast; end
end
complect = Complect :event
Sign up to leave a comment.
Паттерны проектирования на Ruby