我们正在为GIS应用程序开发一个扩展（在C＃.NET环境中），它将具有预定义的类型 对于真实世界对象的建模，从 GenericObject 开始，然后转到更具体的类型，如管道和道路及其详细的属性和方法，如BottomOfPipe ，直径等。
肯定会有一个对象模型，接口，继承以及TypeLibrary中的许多其他重要部分，到现在为止我们修了一些。但是你可能知道，设计一个对象模型是一项非常模糊的工作，而且（我知道的是），可以通过许多不同的方式和许多不同的结果和弱点来完成。
在设计 OM 时是否有任何明确的规则：层次结构，定义接口的方式，抽象和 coclasse s enum s？
有任何建议，参考或实践吗？
答案 0 :(得分：3)
一些好的：
SOLID
S 单一责任原则
O 笔/封闭原则
L iskoff替代原则
我 nterface隔离原则
D 依赖倒置原则
此处提供更多信息和更多原则： http://mmiika.wordpress.com/oo-design-principles/
答案 1 :(得分：1)
答案 2 :(得分：1)
他们说了什么，而且看起来你正在为真实世界的实体建模，所以：
您可以使用继承和组件来减少代码/模型，但只能使用与底层域有意义的方式。
例如，具有Diameter属性的Pipe类是有意义的，而具有GeometryType属性GeometryType.Pipe的DiameterizedObject类（具有Diameter属性）则不会。两种模型都可以使用，但前者明显对应于问题域，而后者则实现了人为（非真实世界）的观点。
另外一条线索：当你发现自己在代码中发现了一些你从一开始就没有计划的新功能时，你就知道你已经拥有了正确的模型 - 它们只是“自然地”脱离了模型。例如，您的模型可能具有管道和连接类（作为连接适配器），足以解决（例如）将不同直径的管道相互连接并计算流速，最大压力和结构完整性的直接问题。您后来意识到，由于您准确地（在域的要求内）建模管道和连接点的结构和连接属性，您还可以从连接的管道创建一个JungleGym对象，并正确计算它将承受多少结构负载。
这是一个极端的例子，但它应该得到重点：正确的对象模型支持扩展，并且经常显示有益的意外属性和功能（而不是错误！）。
答案 3 :(得分：1)
Liskov Substitution Principle，通常用“is-a”表示。 OOP的许多例子最好不要使用“has-a”（在c ++私有继承或显式组合中）而不是公共继承（“is-a”）
获得正确的继承是难以。使用接口（纯虚拟类）这样做通常比基类/子类更容易
答案 4 :(得分：0)
查看面向对象设计的“原则”。这些都为您提出的所有问题提供了指导。
参考文献：
查看上述网站上的“设计原则”文章。它们是最好的参考资料。
答案 5 :(得分：0)
“BottomOfPipe”？这是另一种说道路下方管道深度的方式吗？
任何类型的设计都很困难，可以采用不同的方式。无法保证您的设计在创建时能够正常工作。
设计滚珠轴承等人的优势在于确定哪些有效，哪些无效。软件没有那么多时间或硬数据。
以下是一些建议：