我正在努力理解本体论基础知识。 这是一个例子：
我的问题是了解什么是“2009大众CC”（作为汽车模型）。如果你将产品模型作为本体中的一个子类 - 突然间你的本体变得臃肿，有数千个“汽车”的子类。那是多余的。同时我们不能说“2009 VW CC”是一个实例，至少它不是一个类的实质实例。
区分常规实例和材料（不同的物理对象）是否有意义？
另一方面，如果两者都是实例（具有不同性质的话），那么实例如何继承非类的属性/关系？
答案 0 :(得分：5)
我讨厌说这取决于，但这取决于。
如果您需要对世界上每辆车进行建模，并且有可以调用它们的方法（例如“更换轮胎”，这是一个每个型号都有很大差异的过程）那么是的，你要去有很多臃肿的课程，因为你的现实世界的情况也很臃肿。
如果您只想拥有一个原型车图片数据库，并且您不开车是否是您邻居的实例或您姐姐的实例的图片，那么您可以放弃底层。 “2009 VW CC”很可能是一个实例，即使你可以想象它也是另一个模型中的一个类。
或者，也许你根本不需要把它变成一个真正的子类。一个简单的参考可能就足够了。例如，一家保险公司知道大量的汽车模型和年份，但开发人员不会为每个人编写一个子类。相反，他们有一个汽车模型数据库，其中一行代表2009大众CC。当您为汽车投保时，他们会创建一个“保险车”实例，并参考“2009 VW CC”实例。
这并不严格遵循“对'a-a'关系使用继承”，但所有车型的操作都是相同的 - 它只是更改的参数（例如每年的保险价格），以及新车型记录在数据库中，而不是代码中。
这里假设您可以将差异模型之间的差异建模为汽车上相同方法的参数。
（旁白：当iPhone开始通过电话公司网站上市时，我注意到它打破了他们的班级模式 - 他们的网站似乎在一个页面上处理了几十个品牌和型号的手机 - 可能是使用一个简单的数据库手机及其功能 - 然后需要一个专门的页面来处理iPhone型号，大概是因为他们的课程需要新的特殊方法来支持iPhone销售的某些方面。自动销售台会说“按1购买手机。按2购买iPhone。“）
答案 1 :(得分：1)
你倒退了。
2009 VW CC继承自班级car。因此，2009 VW CC需要了解car，但car不需要了解2009 VW CC。虽然我们偶尔会在现实中使用术语“子类”，但car对其任何子类都一无所知。
更有趣的是，如果你考虑原型继承（比如在javascript中），其中对象直接从其他对象继承（想象一下，如果你的2009 VW CC继承了邻居的2009 VW CC的方面）。实际上，这是如何实现的，即新对象有一个秘密指针，指向它们继承的对象。如果您考虑这个秘密指针，您可以看到原始对象如何不会膨胀。
现在，如果您建议多重继承和长家族树可能导致混乱的结构，那么我会同意你的看法。
答案 2 :(得分：0)
我真的同意Oddthinking。另外，如果你需要汽车模型作为课程，＆＃34;突然间你的本体变得臃肿，有数千个汽车的子类＆＃34;实际上不是问题。为什么会这样？你只需要定义类而不是个人，你可能会有一个抽象的＆＃39;本体论，基础课程和“具体”课程。本体，具有代表现实世界中特定情况的类。这不是OOP，定义实际上介于实例和类之间的千个类并不是什么大不了的事，至少从概念上讲，没有人会认为这个＆＃39;膨胀＆＃39;或以任何其他方式奇怪。事实上，他们一直在我的领域（生命科学，我们通常不关心我们体内的蛋白质P53，所以P53是一个类，即使它也用于模拟一个类）记录在关系数据库中。）
除此之外，我的经验是像Virtuoso这样的工具似乎针对少数类和许多实例的情况进行了优化。事实上，当我将Virtuoso中的数百万个课程转化为实例时，我观察到了显着的性能提升。所以，它很复杂......