以OO设计时的一些疑惑

   OO是不是好的？在OO的时候有关联的对象如何设计？不同的系统面临的问题可能大为不同，则解决的方式也各异。最近做项目的过程中产生了一个疑惑，以前没怎么注意过，但这次却让我相当郁闷。具体如下：

    举例：
产品Product，企业Company，ProductRoom为用于关联企业Company和产品Product的对象。如果以面向对象的方式和松散耦合的原则设计的话，Company和Product将没有任何的有关联的属性，他们通过ProductRoom相互查询。这样要想知道Product是属于哪个Company就只能通过ProductRoom而获得。

    另外，一般在数据库中ID是没有任何业务逻辑的，设为自动增长，且用于ProductRoom中将Company和Product关联的属性用的ID，则Company，Product的ID都存在于ProductRoom中。

    每个产品都是属于某企业（Company）的，所以产品（Product）在增加的时候同样要加入到产品库中（ProductRoom），但是由于产品的ID是自动增长的，那么在产品（Product）存入数据库之前是无法知道其ID的，那么ProductRoom如何获取产品（Product）的ID是非常重要的。但如果得不到产品（Product）的ID，由于产品（Product）中没有任何可以知道其归属的属性，所以产品（Product）将不属于任何企业。这是非常严重的。

    这些问题是我最近做项目碰到的，由于前期是像上边说的那样设计的低耦合的对象，在后来开发中发现了严重的问题。于是我在产品（Product）中增加了一个企业ID的属性，这样不但查询时方便，之前说的那个问题也轻松解决。所以我觉得设计对象不是纯OO就好，稍微有些关联不但能提高效率还能解决可能很严重的问题。


    问题已经解决，这次的收获不小。在设计对象的时候不要死抱着OO不放，要灵活应对。机械的运用不如不用。

OO的目标模拟人类思考方式写代码读代码

你说的问题明明是
由于你考虑了一种机械的OO原则
而非OO的本质。
ProductRoom在现实中会存在么？
他的功能你都无法正确定义。。。
所以才有如上的麻烦。。。

记住OO的本质是人类考虑方式。
而且会有适当的冗余
你认为产品上会不印厂家名称么？

所谓的“解耦”并不是简单的在两个类之间搞一个传声筒。

解耦......不该是这样解的吧?似乎用的场所就不...

OO更多是些思想，思想只能在潜移默化中引导行程和方向，而非具体实用工具。万事灵活处理为好，不应拘泥于一些概念和方法。