我们正在为 GIS 应用程序开发一个扩展（在 C# .NET 环境中），它将具有用于建模现实世界对象的预定义类型，从GenericObject开始，并使用其详细的属性和方法进入更具体的类型，如Pipe和Road像 BottomOfPipe、Diameter 等。
当然，TypeLibrary 中会有Object Model、Interface、Inheritance和许多其他重要部分，现在我们已经修复了其中的一些。但是您可能知道，设计对象模型是一项非常模糊的工作，并且（据我所知）可以通过许多不同的方式完成，并且可以通过许多不同的结果和弱点来完成。
在设计OM时是否有任何不同的规则：层次结构、定义Interface s、abstract和coclasse s enum的方式？
有什么建议、参考或实践吗？
几个不错的：
坚硬的
单一责任原则开放/封闭原则L
iskoff替换原则接口隔离原则依赖倒置原则
更多信息和更多原则在这里： http: //mmiika.wordpress.com/oo-design-principles/
查看领域驱动设计：解决软件核心的复杂性。我想它会回答你的问题。
他们所说的，加上看起来你正在为现实世界的实体建模，所以：
您可以使用继承和组件来减少代码/模型，但只能以对底层域有意义的方式。
例如，具有 Diameter 属性的 Pipe 类将有意义，而具有 GeometryType.Pipe 的 GeometryType 属性的 DiameterizedObject 类（具有 Diameter 属性）则没有意义。两种模型都可以工作，但前者显然对应于问题域，而后者实现了人工（非现实世界）视角。
一个额外的线索：当你发现自己在代码中发现了你从一开始就没有计划的新特性时，你就知道你的模型是正确的——它们只是“自然地”从模型中消失了。例如，您的模型可能有 Pipe 和 Junction 类（作为连接适配器）足以解决（例如）将不同直径的管道相互连接并计算流速、最大压力和结构完整性的直接问题。您后来意识到，由于您准确地建模了管道和连接点的结构和连接属性（在域的要求范围内），您还可以从连接的管道创建一个 JungleGym 对象，并正确计算它将承受多少结构负载。
这是一个极端的例子，但它应该明白这一点：正确的对象模型支持扩展，并且经常表现出有益的意外属性和特性（而不是错误！）。
Liskov 替换原则，通常用“is-a”来表达。OOP 的许多示例最好使用“has-a”（在 c++ 私有继承或显式组合中）而不是公共继承（“is-a”）
获得正确的继承权是困难的。使用接口（纯虚拟类）这样做通常比基类/子类更容易
查看面向对象设计的“原则”。这些对您提出的所有问题都有指导方针。
参考：
查看上述网站上的“设计原则”文章。它们是可用的最佳参考。
“管底”？这是另一种说法，即道路下方管道的深度？
任何一种设计都是困难的，可以通过不同的方式完成。无法保证您的设计在创建时会起作用。
设计滚珠轴承等的人的优势是多年的经验和数据来确定哪些有效，哪些无效。软件没有那么多时间或硬数据。
这里有一些建议：