JiveJdon Community Forums
在线209人 Home | 论坛 | 培训咨询 | 精华 | 查搜 | 注册 | 登陆 |
首页 » 论坛 » 设计模式、框架和架构
???en_US.forumThreadPrev.name??? 上一主题
Go back to the topic listing   返回主题列表
???en_US.forumThreadNext.name??? 下一主题
这个主题共有 9 回复 / 1 页 [ ]  发表新帖子  回复该主题贴
wisedragon

发表文章: 9
注册时间: 2006年04月03日 22:14
给他发消息
###都是设计模式惹的祸-----下面不知道该怎么写了### 发表: 2006年04月03日 22:18 回复
我现在在做一个分类信息的一个系统
我按照 <<工厂方法设计模式>>

抽象的 info类
GenericInfo(一般的信息),HouseInfo(房产类信息),
JobInfo(招聘类信息),TradeInfo(交易类信息) 都是 Info 类的子类

InfoDAO接口
(GenericInfoDAOImp,HouseInfoDAOImp,JobInfoDAOImp,TradeInfoDAOImp 实现InfoDAO接口)

我觉的设计很完美了,可当知道一个infoId 的时候我不知道到底用哪个具体的DAOImp类去数据库查找详细信息呢

晕了 晕了,请高手指教更好的设计模式
wisedragon

发表文章: 9
注册时间: 2006年04月03日 22:14
给他发消息
Re: ###都是设计模式惹的祸-----下面不知道该怎么写了### 发表: 2006年04月03日 22:25 回复

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

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

发表文章: 9
注册时间: 2006年04月03日 22:14
给他发消息
Re: ###都是设计模式惹的祸-----下面不知道该怎么写了### 发表: 2006年04月04日 13:57 回复
/**
* 抽象的工厂
*/
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) 方法去得到这个具体的信息

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

发表文章: 9
注册时间: 2006年04月03日 22:14
给他发消息
Re: ###都是设计模式惹的祸-----下面不知道该怎么写了### 发表: 2006年04月04日 13:59 回复

/**
* 抽象的工厂
*/

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) 方法去得到这个具体的信息

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

banq

发表文章: 9074
注册时间: 2002年08月03日 17:08
给他发消息
Re: ###都是设计模式惹的祸-----下面不知道该怎么写了### 发表: 2006年04月04日 19:56 回复
使用设计模式需要分析场景,也就是确立分析模式后,才使用设计模式,感觉你这里使用设计模式替代分析模式来解决需求。

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

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

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

发表文章: 11
注册时间: 2006年04月10日 21:23
给他发消息
Re: ###都是设计模式惹的祸-----下面不知道该怎么写了### 发表: 2006年04月11日 09:12 回复
我也遇到了一个类似的问题,事实上你在用工厂的时候,我个人觉得你的DAOImpl应该知道自己是哪个属于哪个表的,或者象我现在这样子设计一个表其中的k**是category和id,其属性求这个所有对象的合集(所有加在一起最大),因为进度原因我也没有时间考虑更多的好办法!希望大家一起来讨论一下!
wangyongsoft

发表文章: 1
注册时间: 2006年02月22日 16:21
给他发消息
Re: ###都是设计模式惹的祸-----下面不知道该怎么写了### 发表: 2006年04月12日 12:59 回复
设计模式只是前人解决某类问题时,所采用的比较优的解决方案,它的前提是遇到问题。如果只是为了使用模式而使用模式,那么必然到系统的结构没有任何的帮助,反而会使系统的复杂度增加。
从你的描述了解,你并没有分析出你所遇到的问题,也就是说,你根本就没有问题,你所谓的问题只是如何去套用某个模式的使用问题。

yangylsky

发表文章: 3
注册时间: 2005年01月26日 18:45
给他发消息
Re: ###都是设计模式惹的祸-----下面不知道该怎么写了### 发表: 2006年05月19日 17:57 回复
HouseInfo,JobInfo,TradeInfo等都应该是接口,分别由对应的工厂返回。
还很无知啊

发表文章: 13
注册时间: 2006年06月14日 02:35
给他发消息
Re: ###都是设计模式惹的祸-----下面不栏迷趺葱戳?## 发表: 2006年07月07日 22:30 回复
电脑是不会自己去凭空处理变化的事情的,你都没有想好怎么去处理,电脑当希有是不会的啦。在代码中加入处理的代码吧!
santafeng

发表文章: 47
注册时间: 2006年06月28日 10:48
给他发消息
Re: ###都是设计模式惹的祸-----下面不知道该怎么写了### 发表: 2006年07月09日 23:57 回复

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

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

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

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

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

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

特别提醒各位,不能滥用设计模式OO进行业务设计。

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

以上属于个人见解,如有悟道请批评。
欢迎加**群讨论speed框架和java:5338343
这个主题有 9 回复 / 1 页 [ ]
???en_US.forumThreadPrev.name??? 上一主题
Go back to the topic listing   返回主题列表    返回页首  返回页首
???en_US.forumThreadNext.name??? 下一主题
热点TAG: AOP cache DDD EJB 集群 设计模式 Hibernate IOC JiveJdon OO RBAC Spring Struts
查询本论坛内 回复超过的热门帖子
快速发表回复
标题
 
粗体 斜体 下划线 插入图片 插入代码 插入url链接 插入附件
内容
 

解惑之道在J道 ,打造中国最具影响力的的企业软件社区
OpenSource JIVEJDON v3.0 Powered by JdonFramework Code © 2002-08 jdon.com

anti spam