我正在开发一款RoR应用程序，但这是OOP战略的一般性问题。考虑存储多种类型的引用的情况：书籍，文章，演示文稿，书籍章节等。每种类型的引用都是层次结构的一部分，其中常见行为位于最常见的继承点，并且在数据库级别我使用单表继承。通过使用select选项设置类型，所以假设我输入数据就好像它是一本Book，但后来才意识到它只是一章。因此，我通过选择“Book Chapter”来更改引用类型，然后将更新发布到现有模型/表单。问题是处理这个问题的正确策略是什么？
一方面，最好转换DB中的现有记录以避免ID耗尽，并可能节省创建/删除记录的操作。然而，这往往会使更新策略变得复杂。
另一方面，使用旧对象创建新对象（和记录）以初始化要保留的值，然后删除旧对象，似乎更符合一般对象方向。我认为这在对象空间（堆）方面更有意义，我认为它更像是一般系统的想法。
然而，我没有把它钉死，在坐了一会儿之后，我正在向这个社区投球，看看这样做的“正确”方法是什么。
答案 0 :(得分：1)
您所谈论的转型似乎并不能保证新记录甚至是新对象。
您引用的每个条目都具有相同的格式。他们是兄弟姐妹，父母和孩子的文本块。例如，章节可以具有文本块，其具有父书和儿童尾注。它们仅在数据库级别上根据其类型进行区分，其本身可以是字段。
所有你需要的是一个模型来处理这些'元素'取决于它是否被标记为书或章等。如果一个元素被标记为章节，但没有父元素，例如，然后你可以在保存到数据库时将其标记为“书”。
更改元素标记的方式不会更改元素，只会更改其查看方式。只要元素知道如何找到它的子元素，数据就会以相同的方式计算。就模型而言，它只是你担心的一个因素。其余的工作在UI中完成。
答案 1 :(得分：1)
首选不可变对象，换句话说：第二种策略。你的对象本身可能不是一成不变的，但减少可变性通常是朝着正确方向迈出的一步。
除此之外，这是更自然的方式。一般来说，OOP术语无法改变对象的类型。在你的情况下你可以，但它仍然是一个尴尬和不寻常的事情。
另一方面，如果您的对象由相同（相同）的类表示，并且通过设置高级属性来更改类型，则可以认为重新创建对象是过度的。
尽管如此，减少可变性是一个很好的想法，但如果你的课程已经设计为可变的，那么它可能不值得。 （在特殊情况下，从语言的角度来看，实际上只有一个实际的类）