###都是设计模式惹的祸-----下面不知道该怎么写了###

还有一个问题
HouseInfo(房产类信息),JobInfo(招聘类信息),TradeInfo(交易类信息)

都有一些单独的属性 在数据库中我该用一个表
还是个每个类建一个表好呢

/**
* 抽象的工厂
*/
public interface InfoFactory
{
public Info createNewInfo(Info newInfo);

public Info createInfo(int infoId);
}
/**
* 房产类信息工厂
*/
public class HouseInfoFactory implements InfoFactory
{
public Info createNewInfo(Info newInfo)
{.......... }

public Info createInfo(int infoId)
{..........}
}
/**
* 招聘类信息工厂
*/
public class JobInfoFactoryimplements InfoFactory
{
public Info createNewInfo(Info newInfo);
{.......... }
public Info createInfo(int infoId)
{.......... }
}
...........
我的思路 和 设计是这样的 但家看看设计思路对吗

可这样遇到一个问题: 就是在action 控制层 当知道 infoId 时候 不知道到底该用哪个具体
工厂的 createInfo(int infoId) 方法去得到这个具体的信息

//或还有其它模式比较好解决这类系统问题吗 有人提到用 <<观察者模式>>

/**
* 抽象的工厂
*/
public interface  InfoFactory
{
  public Info createNewInfo(Info newInfo);
  
  public Info createInfo(int infoId);
}
/**
* 房产类信息工厂
*/
public class HouseInfoFactory implements InfoFactory
{
  public Info createNewInfo(Info newInfo)
  {.......... }
  
  public Info createInfo(int infoId)
  {..........}
}
/**
* 招聘类信息工厂
*/
public class JobInfoFactoryimplements InfoFactory
{
  public Info createNewInfo(Info newInfo);
   {.......... }
  public Info createInfo(int infoId)
   {.......... }
}
...........

我的思路 和 设计是这样的 但家看看设计思路对吗

可这样遇到一个问题: 就是在action 控制层 当知道 infoId 时候 不知道到底该用哪个具体
工厂的 createInfo(int infoId) 方法去得到这个具体的信息

//或还有其它模式比较好解决这类系统问题吗 有人提到用 <<观察者模式>>

使用设计模式需要分析场景，也就是确立分析模式后，才使用设计模式，感觉你这里使用设计模式替代分析模式来解决需求。

根据你的需求，房产类信息和招聘类信息属于四色图中的description，是一种目录式对象。它们属于category。

当然它们都属于信息，但是信息这个抽象的域范围很广，域范围太广就没有意义了。

因此，你以info为抽象的提炼方式是不对的，更何况你用工厂模式来实现了。

我也遇到了一个类似的问题，事实上你在用工厂的时候，我个人觉得你的DAOImpl应该知道自己是哪个属于哪个表的，或者象我现在这样子设计一个表其中的key是category和id，其属性求这个所有对象的合集（所有加在一起最大），因为进度原因我也没有时间考虑更多的好办法！希望大家一起来讨论一下！

设计模式只是前人解决某类问题时，所采用的比较优的解决方案，它的前提是遇到问题。如果只是为了使用模式而使用模式，那么必然到系统的结构没有任何的帮助，反而会使系统的复杂度增加。
从你的描述了解，你并没有分析出你所遇到的问题，也就是说，你根本就没有问题，你所谓的问题只是如何去套用某个模式的使用问题。

HouseInfo,JobInfo,TradeInfo等都应该是接口，分别由对应的工厂返回。

电脑是不会自己去凭空处理变化的事情的，你都没有想好怎么去处理，电脑当希有是不会的啦。在代码中加入处理的代码吧！

一般我们的做法，对象跟对象之间当然有共同特性才能抽取出来，如果GenericInfo(一般的信息),HouseInfo(房产类信息),
JobInfo(招聘类信息),TradeInfo(交易类信息) 都是 Info 类的子类
那他们都有一个特性就是信息。所以信息是一个属性，其他各自里面必须有自己的特性。

但是你这样设计出来的表应该只有一个主表信息、从表类型类型表，然后把对象GenericInfoDAOImp关联查询出主从表对象队列。

只设计一个主信息表是实现不了的，如果抽象与二维表对应关系不明白，请参考多些oo的书籍和数据库设计书籍，不要盲目使用oo设计系统，特别是针对数据库的一些系统。

提一下speed框架，因为它针对的表、视图对象逻辑设计模式，针对表进行操作，简单并不难理解，如果你的系统大了以后用oo的思维去实现数据库操作一定左右为难。

打个比方，原系统角色有四种：匿名用户、注册用户、特殊用户、管理员四类各自权限不同并可以配置菜单权限，oo是设计四个用户类。现在需要修改系统满足用户角色，发现需要继续增加100种角色。当初设计时候没有考虑到针对数据库逻辑的应用，因为角色与权限菜单都是多对多关联，硬性设置四类对象可以实现，但现在增加100种角色那就不可能增加100个类和针对该类的操作。

如果使用普通三、四层模式不抽象oo即可满足以后扩展需求，针对表、视图对象逻辑进行开发，请参考：
http://sourceforge.net/projects/speedframework/
例子代码与框架代码。

特别提醒各位，不能滥用设计模式与oo进行业务设计。

简单的来说当你设计出表名，表关系即可进行代码开发，并不怕表字段逻辑的扩展修改。这样简单的程序对于接手维护和自身团队开发是一种方便。开发员并不需要了解该类对象的逻辑，只要dba给出一条可用的sql即可实现填鸭子。

以上属于个人见解，如有悟道请批评。
欢迎加qq群讨论speed框架和java：5338343