Рассмотрим этот неуклюжий надуманный пример:
class Notification
def should_send?
enrollment_status ? true : false
end
end
class Sms < Notification
attr_reader :enrollment_status
def should_send?
super(enrollment_status)
# a method call dealing with logic specific to text messages would go here
end
end
class PhoneCall < Notification
attr_reader :enrollment_status
def should_send?
super(enrollment_status)
# a method call dealing with logic specific to phone call would go here
end
end
Этот пример не будет работать, но представьте, что существует еще несколько подклассов уведомлений, и dry не очень-то добавлять false if user.unenrolled?
к каждый подкласс. Однако каждый подкласс также будет реализовывать свой собственный пользовательский logi c. Ключевым моментом является то, что родительская проверка уведомлений должна заменять настраиваемые logi c в подклассах. Другими словами, если вызов родительского метода возвращает истину, тогда отложите до результатов в вызове дочернего метода, и если родительский вызов возвращает ложь, исходный вызов дочернего метода должен возвращать ложь независимо от пользовательского logi c.
Несколько примечаний / вопросов:
- Я понимаю, что в этом примере есть некоторые причуды, это странно, но он точно отражает ограничения существующей работы.
- Возможно ли короткое замыкание из вызова супер-метода и вернуть этот результат до выполнения logi c в дочернем методе?
- Должен / могу ли я передать весь дочерний элемент родительскому в супер-вызове и составить весь logi c проверьте там?
- Возможно, я здесь не в теме, я все это перепутал? Есть ли лучший способ управлять проверкой как дочерних, так и родительских результатов?