那么你必须要意识到的第一件事是OOAD("面向对象的分析和设计")是一种工具,而不是达到目的的手段.你从这个过程中得到的是一个模型,而不是你正在建模的真实表现.该模型做出了某些假设.该模型的目的是解决您遇到的问题.
那么你怎么知道如何设计对象呢？你怎么知道你做得对吗？最终结果:它解决了你的问题吗？
因此,对于汽车示例,在某些模型中,汽车数量可能只是整数,例如通过交通模型中的交叉口的汽车流量.在这样的模型中,你很少关心汽车的品牌,型号或结构,只关注数量.你可能会关心车辆的类型,例如卡车或汽车(例如).您是否将其模型化为具有Car或Truck类型的Vehicle对象？或者只是单独的carCount和truckCount计算？
简短的回答是:无论哪种效果最好.
某物作为对象的正常测试是否有行为？请记住,最终对象=数据+行为.
所以你可能会说汽车有以下状态:
您可能只关心其中的一小部分:选择相关的任何内容.赛车游戏可能会更详细地介绍车轮,例如它们有多热,磨损程度,车宽和胎面类型等等.在这种情况下,Wheel对象可以说是所有状态的集合(但行为很少),因为Car有多个车轮并且车轮可以互换.
因此,提出了关于对象的第二点:对象可以存在,因为关系使得对象代表一组完整的数据.因此,车轮可以具有胎面,宽度,温度等.你不能把它分开并说汽车有胎面而没有轮宽,所以将Wheel作为一个物体是有道理的,因为它的整体轮子是可以互换的.
但同样,这对于做什么有意义吗？这是关键问题.
不要从分类开始 - 似乎人们太急于开始构建继承层次结构.
记下具体的具体方案列表 - 您的应用程序将逐步完成的工作.对象模型只有在它完成您需要它做的事情时才有用 - 所以从场景开始回过头来查看可以摆脱每个对象和行为的常见对象和行为.
确定您的方案中的"角色" - 不一定是实际的类名称 - 只是模糊的"角色",当您通过具体方案思考软件的工作方式时,这些角色会出现.这些角色可能稍后成为类,接口,抽象类 - 无论您需要什么 - 一开始它们只是做一种工作的占位符.
弄清楚每个角色"做什么".关键是拥有一堆命名角色 - 用于识别对象将要执行的操作.这是关于提取每个角色可以做的一系列事情 - 他们可以完成整个事情,或者将一堆其他对象组合在一起完成工作,或者他们可能协调工作......这取决于你的场景.
OOD/OOP中最重要的事情 - 对象是做什么 - 而不是它们里面的东西 - 它们的作用.
不要在早期考虑继承 - 因为它会将您绑定在过于复杂的层次结构中,并让您考虑面向SQL的编程而不是面向对象的编程.继承只是共享公共代码的一种方式.还有很多其他方法 - 委托,混合,基于原型的编程......
以下是我提出的一些指导方针,以帮助解决此问题: