Многое зависит от вашего домена приложения.Я не думаю, что у нас здесь достаточно информации, чтобы точно знать, каков правильный подход в вашей ситуации.Например, если ваше приложение в первую очередь занимается управлением и составлением отчетов о расписаниях / часах сотрудников и предприятий, а также отчетами по этим графикам, может иметь смысл иметь единую таблицу «часов» и относиться к ней полиморфно.Это может выглядеть так:
class Business < ActiveRecord::Base
has_many :hours, :as => :scheduleable
end
class Staff < ActiveRecord::Base
has_many :hours, :as => :scheduleable
end
class Hour < ActiveRecord::Base
belongs_to :scheduleable, :polymorphic => true
end
Здесь вы все равно можете использовать STI для разветвления различных часовых функций, если это необходимо.(Примечание: используйте единственное число при наименовании вашей таблицы модели, то есть BusinessHour, а не BusinessHours):
class BuisnessHour < Hour
validates :some_business_hour_rule
end
И т. Д.Ключевой вопрос с STI заключается в том, что, учитывая то, что я знаю о своем домене, вероятно, я бы добавил много атрибутов / столбцов, специфичных для подкласса, так, чтобы у меня было много пустых столбцов, например, в строке в таблице часов, представляющейобъект StaffHour, который не использует многие специфичные для BusinessHour атрибуты / столбцы?
Если это так, то, возможно, STI не имеет смысла для вас.Но если из того, что вы знаете о проблемах вашего приложения, основное различие между подклассами является программным, а не ориентированным на данные, где существуют разные проверки и бизнес-правила для работы в основном с идентичными данными, тогда STI может быть правильным решением.
Я бы сел с владельцем Продукта (кем бы он ни был) и другими инженерами в команде (если таковые имеются) и занялся им.Если вы команда из одного человека, в любом случае, подумайте о том, что ваше приложение будет делать с этими моделями в будущем.Если вы знакомы с UML, это может быть очень полезным инструментом для визуализации модели данных в форме, отличной от кода.Если нет, то это может быть хорошим поводом немного поучиться.Подобные решения могут оказать огромное влияние на общую стабильность кода в будущем.
РЕДАКТИРОВАТЬ:
Еще один вопрос, который нужно задать себе, действительно ли правило для конкретного бизнеса относится к объекту Hour?Возможно, более уместно иметь такие операции над самой бизнес-моделью и сохранять простоту часов, если вы действительно не представляете бизнес или специфическую для персонала операцию, которую вы бы вызывали для самой модели часов.Например, это:
class Business < ActiveRecord::Base
def calculate_monthly_cost
# operates on hours
end
end
имеет для меня больше смысла с точки зрения ООП / SRP, чем это:
class BusinessHour < Hour
def calculate_business_cost
# operates on business or uses business-specific rule
end
end
По крайней мере, это те вопросы, которые вам нужно задатьопределить правильный подход.