我为大学过程建模，其中我有三个班级：学生，主题和学位
学位有自己的科目，学生有他们已经通过的科目列表，学生也应该属于单一学位计划。
从编程角度来看，我应该如何将学生与他/她的学位联系起来？我是否应该将度数作为对象的参考，我应该将ID作为度数吗？还有更好的选择吗？
答案 0 :(得分：0)
从编程角度来看，我应该如何与学生联系 他/她的学位？我应该通过学位作为对象的参考， 我应该为学位制作ID吗？还有更好的选择吗？
我认为这完全没有实际意义。
ID，索引，指针/引用 - 它们通常都是一样的：资源的轻量级句柄。
可能相关的一件事是这些手柄是否不透明。例如，ID或索引肯定是不透明的。你不能直接对它们做任何事情，除非把它们传递到另一个做某事的界面。如果你的目标是隐藏信息和解耦实体，那么这可能是一个好处，尽管指针/引用也可能是不透明的（取决于语言）。指针/引用也可能倾向于以ID和索引不同的方式失效，但仅限于C / C ++等低级语言。
值得注意的是，让您的传出依赖项从更容易更改的代码流向更难更改的代码是有益的。这是因为如果您需要对接口进行重大更改，那么具有易于调整的传入依赖项意味着更改的成本很低。相反，如果传入的依赖关系同样很难改变（例如：为了响应界面变化而言，比界面更改本身更难以适应），那么你就会看到一个非常不愉快的场景。
当然，此外，您希望依赖关系流向稳定的接口。如果您非常确定接口不需要更改，那么您可以更加自信地拥有许多/复杂的传出依赖项。稳定性和易变性因素都值得考虑。
因此，例如，如果Students非常难以改变和/或在界面方面不是很稳定，并且同样适用于Degree，那么您可能不希望耦合这些直接对方。相反，您可能希望引入一个比这两个中的任何一个更简单的实体，这两个实体都依赖于两者，这样如果要么更改，您只需要在响应中间更改这个更简单的对象。这个对象甚至可能使从学生到学位的关联成为一个外部关联，这样你的学生甚至不需要存储任何东西。
我建议不要将类之间的多个关联作为您希望依赖关系流动的方式，而是希望它们从易于改变流向难以改变，不稳定转向稳定。这不是最漂亮的图表，使得代码库更容易更改/维护，就像连接的性质一样。一个简单的事情取决于3个复杂的事情，可能比3个复杂的事情相互依赖。
我不太确定性能是否是您问题的任何部分，或仅仅是设计/可维护性。
如果涉及性能，那么您自然不希望复制任何昂贵的数据。然而，上面描述的这些轻量级手柄都不会这样做，因为它们不会涉及任何深拷贝。然而，如果一个Degree存储一些状态，使每个学生不可避免地不同（意味着我们需要与学生一样多的实例），但是每个学生都有不同的笨重部分，那么我们可能想要将其分成两个独立的实体，每个学生的学位与其他人分享共同数据，以避免重复。也就是说，除非你有充分的理由复制空间局部性或并发性。