谁能写个“新闻发布系统”的面向对象分析和设计的过程?

请大家谈谈,拿到这样一个系统,是怎么进行分析和设计的?怎么处理类与类之间的层次,和通信。

比如把新闻发布系统分为话题:注册登陆、新闻发布、权限管理。

在“注册登陆”系统中怎么分析?其中有表单类,那么新填写的注册、已经填写的注册、已经履行的注册,这些是当成表单类的子类还是表单类的对象,该怎么处理和设计?

按照面向对象分析,其过程应该是对象1:未填写的注册表与对象2:填写后的注册表进行交互

但是实际上,他们并没有通过对象间消息的传递,而更多的通过在注册表类中增加了一个“填写”

的方法完成?这样做会不会给系统整体上的架构增加复杂的成分?

我们一般只做如下设计:

注册表类

属性:字段

方法:新建,填写,删除,修改,添加,撤消


NEW 一个对象,然后它就是一张注册表

NEW 一个对象,然后它并不是一张未填写的注册表,虽然未填写的注册表是它的子集

注册表和为填写的注册表都属于注册表类,但是一个NEW,却不会出现两种对象

男人和女人,都属于人类,但却不能直接从人类进行对象的实例化?

人类的一个对象实例是人,它NEW不出男人或者女人,只有在人类下面细分为男人类、女人类,再NEW才会出现。

这些东西说明了什么,还是你们采用了更科学的方法呢?

我只是把这问题提提,讨论讨论,虽然我知道把“注册类”做为一个整体而不分的那么清楚,设计起来,其实更简单。

仅仅是新闻发布不如采用新浪的方式-动态生成静态页面.

>注册登陆、新闻发布、权限管理

“注册登陆和权限管理”已经有通用解决方案,当然,复杂的数据相关权限ACL需要在业务分析中提及。

下面就是分析“新闻发布”,这个我已经在JdonFramework实现案例中提及,大概模型类图如下:

以前自己也做过一个生成静态页面的新闻发布,我总觉得自己学的程序在架构上很混乱,所以想看看你们是怎么架构的。BANQ给的那个图,我和自己的设计比了一下。我是个初学者,我以前的设计是把“新闻”当作一个类,在BANQ的设计中,关联了两个更细的类,比如其中有一个是新闻类型类。我想他这个应该是把变化的东西分离了出来吧?

顺便问一下“面向对象分析”的方法。使用UML进行统一建模,可是UML是建模的语言,建模的过程有什么方法呢?在J2EE系统中,是不是把系统分N层次,然后找出每层中的类和对象并建模?在别的系统中呢?还有没有什么方法,有什么相关的书籍没?

建模现在采取Evans DDD领域建模设计,领域建模DDD属于XP方式,至于RUP建模,我觉得恐怕迟早会淘汰吧,或者说应用范畴越来越小。

果然被淘汰了,和我想的差不多,原因是我觉得它太复杂了,我喜欢那种一看上去就清晰简单的东西,而且要容易理解。一个好的架构应该可以抽象成现实生活中有的“东西”,这样理解起来就容易多了。

我学“面向对象设计”的时候,发现一个问题,那就是对象的“方法”问题,比如对象要是人的话,他有一个“提交”,或者是“检查”的方法,那是很容易理解的。但是比如有个“表单类”,其中他的方法“添加”。我觉得它这个方法是“被动”的,因为表单自己并不会“添加”,施加给它这个“动作”,或者是“方法”的,应该是个人。所以我认为,我们建模的时候为什么不把一个过程抽象为现实生活中的过程呢,也许它的性能会低一些。虽然我还没有具体去实践,也还没有学过什么J2EE,但是我把我的想法说说:

比如架构一个系统,要涉及到权限,要涉及到功能的“开”,“关”,最基本的做法,我们做每一个操作之前,总是要查询“这个功能被系统打开了或者是关闭了没”,“我们是不是有这个权限”,很自然的,比如是个注册系统,我们在执行“添加”这个动作之前,都必须用到两个方法,第一个检查这个“注册”功能是不是正被开放使用,第二个,我们是不是有这个“权限”进行“添加”操作?那这两个类,我们应该放在哪个类里面去呢,也许我们可以把他分成两个类(权限类,功能类),然后在“注册类”里面加上这两个方法,在执行“添加”之前操作他们。我觉得这样增加了他们之间的“耦合”,也显得很混乱,在一个类里面执行这些操作,是不是把“注册类”这个静的东西动态了?执行这些操作的应该是个人才对啊?就象在现实世界中,我们填写完一张注册表之后,我们并不会直接去“检查”,“添加”他,我们会把他交个一个这方面的人,然后这个人会检查,我是不是有这个权限?我填写的完整没有?然后他跟“注册类”打交道。也就是,用户――>“负责注册模块的人”――>注册类。这样打交道。

权限和功能问题:我们要进行操作时,先找个负责这个操作的人,然后他告诉我,比如,“这个功能被关闭了”,“你的操作已经成功了”,之类,我们不直接跟类打交道,因为我们不能充当每方面的“专家”

这样做的好处,松耦合,也省的每次执行操作之前都要在方法里面嵌套方法,我们可以等用户登陆的时候,就找到那个相关的人,把系统的功能开放了哪些和这个人可以进行的操作记录在表里,进行操作的时候就不必再查数据库了,应该更快些?然后用户退出的时候,就删除相关的记录?

我觉得MVC模式里面的C,有时候他就充当了“这个人”的角色,但其实这个人可以分的更细些。

这些问题我也是刚想的,你们的想法是?或者,说说这样做的缺陷

我觉得软件这东西,只会越来越容易理解,越来越能用现实中的东西去抽象。复杂的东西,最后都会被淘汰,我看你那DDD,失血模型,我一看就有点头昏,应该也会被替代掉。

我用我的理论架构一个“新闻发布系统”,如下

我把“新闻发布系统”当成一个公司,系统的架构图就是:

用户(操作者)――>检查员(检查操作者所用的功能是否开放中,操作者的权限是否够,操作者是否登陆)――>业务员(执行“专业”的业务,例如“添加”,“修改”,“删除”)

我可以把“检查员类”定义成一个抽象类,里面比如说有个检查权限的方法,然后实现它的类就可以是“新闻权限检查员”,“登陆权限检查员类”,你可以选择一个成员对应一个实际的静态的类(比如注册表权限检测员对应注册表类),也可以用一个人类对应多个静态类。

操作者跟业务员交流,业务员跟熟悉的业务交流,这就是我的架构的实质。这样可行吗?我讨厌很多类,关系又很复杂,搞又搞不清楚,用“业务员”跟“业务”这样的思想行得通么?请指教

>权限和功能问题:我们要进行操作时,先找个负责这个操作的人,然后他告诉我,比如,“这个功能被关闭了”,“你的操作已经成功了”,之类,我们不直接跟类打交道,因为我们不能充当每方面的“专家”

>用户(操作者)――>检查员(检查操作者所用的功能是否开放中,操作者的权限是否够,操作者是否登陆)――>业务员(执行“专业”的业务,例如“添加”,“修改”,“删除”)

非常不错,就是这个意思,现在我们讨论下一步,如何使用代码实现“检查员”和“业务员”分离?这是设计问题,这个实现有多个方式:

1. 代理模式,使用权限代理人,这是Jive实现的原理,可看看它的源码,缺点是,一个检查员对应一个业务员,如果我们业务员有100个,检查员就是100个,很琐碎?而且检查员也是分类的,如有的检查员都属于是A权限检查,有的都属于是B权限检查,如果A权限变化,涉及多个检查员修改,不利用权限拓展修改了。

2.使用动态代理直至AOP,在AOP中有一个角色叫Advisor,它实际就是一个检查员的意思,通过Advisor,我们可以通过配置设定将Advice或拦截器跟住哪个业务员。

以上原理如果你要看源码,可以瞧瞧JdonFramework的Message源码,检查员配置是通过配置实现的,与业务分离了,更深入的权限可以参考JiveJdon3。当然与JdonFramework同列SUN公司企业应用目录的appfuse也是一个范本,使用Spring+Acegi实现,实现起来比较复杂,而且功能演示就那么一点点,你可以下载看看。

你前面oo思路是正确的,就应该是这样符合我们思考习惯的思路,Evans DDD不是将这个问题复杂化,而是继续引导走下去,你的思路只是分析,如果设计实现呢?DDD提供了建模实现的途径,针对很多问题进行了讨论,因为权限问题已经成为通用的组件框架技术,所以在Evans DDD中并没有谈及权限,而是讨论各种不同复杂的业务系统,这是正确的。

虽然我们具备OO思考习惯,因为我们经历和经验问题,可能觉得DDD复杂,那是因为我们的原因,而不是理论的原因,有时必须搞清楚这个关系,才能判断这个理论是不是昙花一现。

Martin Fowler等一些OO专家著作的PoEAA,原来我批判其操作性不够,讲得好听,实现起来难做,包括其分析模式,还不如四色原型方便,但是DDD在这方面迈出了探索,讲这些包括我们得GoF设计模式付诸于建模实践,最后我们得设计精华浓缩在OO模型上,这是令人激动的。

您说的是有一定道理的,呵呵,我毕竟是个初学者。

DDD我没有深入研究过,我觉得这方面的资料书籍根本不怎么找得到,在您的站点里面也就几篇相关的文章。

我现在也很郁闷,有很多东西我都想好好的把它研究一下。但是这个和生活真是矛盾,我是软件学院毕业的,还是2年的那种,本来可以升本,但自己不愿意,也不想给家里造成很大的经济负担,所以放弃了。

在大学两年里,我根本就没怎么学。JSP,JAVA也就学了半个学期。我现在会的也就是三层的MVC:JSP+JAVABEAN+SERVLET。根据我在家呆了这段时间以来,我看了很多书,“设计模式”,“重构”,“AJAX,”,“SPRING”,“EJB”等太多了,这些都只是大概的了解了一下。

我觉得搞应用是搞应用,现在多少人又了解框架的原理,现在开发做网站的是搞二次开发的,用熟了那些框架基本上就行了。(虽然懂了原理可以更好的做开发)了解原理的人大多数不是成“架构师”那就是在开发“框架”了吧。两个不同的工种。

赚钱和搞技术是两码事,这个物欲横流的时代,搞技术但是没钱,又有多少人能静得下心来?

我个人来说,真想把他们的应用和原理都研究下,可是还得找工做,我现在是不是该先放下原理的东西,把应用学会呢?

根据我分析,现在建站点,绝大多数的时候是需要用框架的,他们更容易快速快发,也更容易维护,扩展等。(关键的地方是框架之间的搭配吧?)

可我是先学J2EE好,还是学“Struts”,“JDON”之类的轻量级的框架好呢?我本来打算先学J2EE的,可这样的话,时间是不是要很久?

真搞不懂,象我这样的人才,怎么连工作都找不到……,真郁闷。哪位大哥大姐帮忙推销一下,呵呵,先谢谢了。

另外,“权限”我没有深入的思考过,我不明白你说的100个业务员,需要100个检查员是什么,权限的主体内容就是“资源”,这个“资源可以有很多不同的操作”,例如“可读”,“可写”,“只读”等。权限系统做到极至了,那也就是对资源的细化。细化到一个类,一个对象或者一个方法,一个变量。细化的程度不同,复杂程度自然不同。我觉得就是(String “操作”,Table “资源表”),一个操作,一个是“资源表”。比如一个人要做注册表的添加操作(String “注册表的添加操作”,Table “资源表”),那么检查员,找到资源“注册表的添加操作”,然后我们就可以查出谁能操作它,一个用户,或者一个组,或者几个组,他们之间用“或”关系,只要是其中的一个,就有权对它进行操作?

理论上来说,资源可以是个“树”状结,例如“注册表的添加操作”,它是不是可以是资源“注册表”下面的节点。我觉得这样做的关键是,你要知道你现在在进行什么样的操作,并把它带进检查的方法(String “操作”,Table “资源表”)。


还有,资源的嵌套问题,就是说,你有权访问“注册表”这个资源,是不是就能进行“注册表”资源下的所有的资源的操作?我觉得要是你每次都能带一个你正在进行的“操作”进那个方法,那这个就不重要了,因为,只要进行“操作”,你就还得重新查一次“资源”。

简化这个模式:你并不一定对每个资源都要进行权限控制吧,那样,这个“资源”也许会大到你不想要的程度,你可以把你想要控制的“那部分”,放在这个“资源”中?

关于操作者(进行操作的这个人),他可能是一个单独的角色,也可能是一个组,所有的操作者,都让一个检查员去进行检查,这个“检查员”没有子类。

如果你是这样的一个模块派一个检查员,一个模块做为一个资源,那样是不是更复杂了,但是也可以,因为检查员是并行的,也就是说,你进行注册表的操作,总不至于叫新闻模块的检查员去检查吧?然后资源那部分,再建个表就是了。(树状结构)

这样的想法会最自然的想法了,现实生活中不也是这样么,检查员必须知道操作员,对资源进行了什么样的操作,他才能做出他有没有权利的判断?

我的模型的难处就在于,你要传入你正在进行的“操作”,这个问题实现起来好象有点难度,可以在表现层,提交一个表单的时候顺便当参数一样,传一个“操作”?

大家可以再讨论讨论。BANQ,要不我去你那帮你公司扫地好了,要是你做我师傅,那我肯定不要几年就能有所建树了。

我们可以对“会员”进行管理,添加,修改,删除等,那为什么我们不可以对“资源”进行管理,规定哪些“资源”可以被哪些人操作,我们甚至可以进行“资源”的添加修改删除,就想,一个仓库,我们新进一批产品的时候,不是也要对这些“资源”进行登记么?

然后再根据实际的情况简化这个模型,要不我就不知道计算机短时间内,能不能有那个运算量了

>那为什么我们不可以对“资源”进行管理,规定哪些“资源”可以被哪些人操作,我们甚至可以进行“资源”的添加修改删除

是可以这样,资源使用一个通用的树组件来完成,如果再结合角色的树结构,它们之间的对应是灵活的,而且是分离的,都可以实现。