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