我正在以一种模型（OrigM）拆分为两个模型（OrigM，NewM）的方式重构我的Rails 5.2应用程序。在代码库中，有对OrigM对象执行update的代码，我现在希望这会导致特殊的行为，其中相关的OrigM和NewM对象将得到适当更新。
执行此操作似乎很简单，就是在OrigM模型中覆盖update，但尝试以简单的方式进行操作会导致无限递归，因为显然甚至在类方法OrigM.update(id, new_attrs)下引擎盖只是find将ID为id的对象并调用update作为其实例方法。
尽管我尚未对它们进行全面测试，但我想出了一些其他可行的方法：（1）通过分别对它们调用write_attribute来更新OrigM属性（似乎不会这样）让我检查验证），或（2）
self.assign_attributes(new_attrs) ## resulting in "dirty" object, then
self.save!
我倾向于第二种解决方案，因为它似乎应该在功能上与标准update所做的工作完全相同。
编辑： 我意识到除非有人问一个问题，否则没有人能真正地回答，所以现在将其重铸为：
问题：是否应该覆盖AR的update方法（在OrigM类中）？
评论员说：“不要这样做，否则您会受到谴责”（说实话，我确定有人会笑）。但是...真的是这样的罪行吗？是否有“杀手级”理由不这样做（您无法与之抗争）？还是只是勉强鼓励的最佳做法？
还：“为什么不做一个不同的事情就不定义一个新方法呢？”好吧...我想我需要对模型做更多的介绍...我不想尝试给出实际的代码，因为它太复杂了。可以说：大多数代码仍然与OrigM对象交互，并且不会了解NewM。仅在体系结构上需要NewM，因为我需要允许多个OrigM共享（属于）单个NewM，以避免数据重复。因此，我想让其余大部分代码保持这种幻觉，即仍然只有OrigM，并且能够照常进行更新。这感觉对我来说是最优雅的解决方案。如果我创建一个新的OrigM#myupdate，将来的开发人员（包括我自己）可能会诅咒我，因为他们试图做一个简单的update，但事情却变得很糟糕。哇，不是必须要知道有一个特殊的更新功能，就像必须知道AR的更新已被覆盖一样令人困惑吗？