整体部分结构与关联类的问题
我正在做一个系统，想用面向对象的分析方法，但在整个框架的设计都没什么问题，主要是在设计具体的类是有点疑问
我现在有以下需求，系统有产品线，每个产品线下会有多种型号
并且产品会分地区销售，不同的地区会有不同的销售时间，例如产品型号MA在地区AA只会在2008销售。
现在我设计一个包含以下对象的结构
产品线类ProductInfo,   产品型号类   ModelInfo，   地区类AreaInfo，   型号状态类ModelStatus(这是一个关联类)

AreaInfo有以下字段
AreaID
AreaName
...其它字段

ProductLineInfo有以下字段
ProductLineID
ProductLineName
...其它字段

ModelInfo
ProductLine//一个ProductLineInfo对象
ModelID
ModelName
...其它字段

ModelStatusInfo
Model//一个ModelInfo对象
Area//一个AreaInfo对象
PhasedInDate//开始销售日期
PhasedOutDate//结束销售日期

ModelInfo与ProductLineInfo有关联，但在实际应用中只需要ProductLineID和ProductLineName，那我在ModelInfo中是否应该取消ProductLineInfo对象，改用这两个字段来代替呢？

ModelStatusInfo的问题也一样。

同时我也联想到在整体部分结构中，有时候是不是也可以用一两个字段来代替整个对象呢？

因为这样构造一个对角的同时，还有内嵌其它对象应该挺费资源的。

我知道具体情况要具体分析，我是指在这种一个对象只用到另一个对象某几个字段时，是否不值得把整个对象内嵌进去？


------解决方案--------------------
Up..
吾欲知其解。
------解决方案--------------------
> 还有内嵌其它对象应该挺费资源的

你认为是浪费资源？ 什么资源？ 网络带宽还是内存？

硬件资源是一方面，同时也要考虑到开发与维护所需的时间也是资源。
因为硬件越来越便宜，所以很多时候会让位给人力资源。
换言之，若用户有一G内存，那么你用300M还是500M就不重要，只有用到2G时才需要考量：
是增加1G内存便宜，还是加多一个月开发时间更好？


------解决方案--------------------
几点意见：
1）在数据库层面，其实对象引用都最终实现为“Id引用”,UML中也可以将一个类对另一个类的引用定义为Id引用
2）ID引用和对象引用并不矛盾，只要你所关注的对象是需要持久化的。考虑一下对象的持久化。你就会发现，对象引用在某种层面一定需要Id引用，并最终在数据库存储中落实这一点。
3）反过来，很多时候Id引用也需要对象引用作为辅助：这既可以在对象加载时立即设置，也可以通过一个属性或方法封装一个根据Id获取具体对象实例的过程。
4）如果你确认一个对象A到另一个对象B的引用最终只需落实到个别字段就可以，而且你认为通过加载B获取B的相关属性是一件较高负载的事情并且你宁愿也被允许为此忽略此后B的（哪怕只是某些A常用的）属性的刷新时，你确实可以把你关注的B的属性直接放到A中。虽然这即使在数据库设计层面也是违反了范式的，但是在某些追求相应的速度对象类型上确实也是可以应用的。这种情形在A和B两种类型的数据量都很大，而B的某些属性在A的使用或呈现中常常需要用到时，更加常见。

世界上有很多规则，有时候违反规则就是真正的遵守规则：权衡并随需而变。

欢迎来我的blog做客，也许有意外收获。