功能,接口,类之间转化,设计的原则的讨论。

03-10-27 hbc20
我想讨论讨论,系统功能,接口,实现类之间的一些关系。

假设一个系统:

已经知道了系统的功能需求,我怎么根据我这些功能建立好设计模型呢?

有些什么一般性的准则么?

也就是说,我怎么知道该定义些什么样的接口,什么样的类实现。

我看模式书上,接口定义的时候好像都是“动词”,而实现类定义的一般都是名词,也就是说是这个动词的主语。

比方说,人喝水,狗喝水,兔子喝水,这样一个语义功能,就会这样描绘:接口是 IeatFood ,而实现类就是people,dog,rabbit。

那么我们可不可以这样理解呢,接口就是功能(动作,能力)?而执行这个功能的主体就是实现类了,这样我们是不是就把系统从现实世界中转化到了计算机设计模型上了呢?这个算是一条捷径吧!

大家讨论讨论呀!

                   

banq
2003-10-27 18:00
功能用例需求中寻找 Domain Object(Entity Object),我称之为基本业务对象,使用接口表现出来。

zingers
2003-10-27 21:42
这个讨论有点意思,楼主的思路是对的,Bang说的Domain object(Entity object)不是持久层的意思吧,而是问题/业务领域的本质功能接口吧?

banq
2003-10-28 12:10
是的,Domain object(Entity object)不是持久层,持久层概念只有在设计实现时才会使用到。

所以我称为基本业务对象,是属于业务领域的本质,如何从系统功能中寻找出正确的本质的基本业务对象,是一个项目成功的开始,也是项目架构的出发点。

如果基本业务对象提炼错误,或偏差,系统的方向相当于走偏了,开发成型后,是无法通过fix bug来解决的。

这里也体现了一个系统的必须要有一个具有丰富经验的设计师或架构师来把握,不能再象过程语言系统那样,由程序员自己想到哪里,开发到哪里。

缺乏这种架构师的公司可以通过聘请咨询公司来解决,J道包括我就提供这样的收费服务,可惜,目前很多公司包括有经验的程序员都没有认识这一点,这样的人员组成的IT行业能不萧条吗?

hbc20
2003-10-29 17:51
斑竹说的非常准确,那么这个基本业务对象是如何提炼呢?斑竹能介绍一些方法和原则么?比方说,看那些方面的书籍,考虑哪些问题?

我的理解是,中国人都讲究五行相克,作为一个软件领域的东西,答案可能我们不能再从软件行业里面来寻找了,软件工程那一套东西,我想是不能再行通了,我们应该学习的是很多现实世界的东西,比方说,一个软件,可能对于不同地域的用户,对于不同思维习惯的人来说,大家的理解都是不同的,这样我们就有必要先学习各种文化,思维习惯了,但是这样学下去,路漫漫了。。。。

请斑竹介绍介绍经验之谈?

猜你喜欢
4Go 1 2 3 4 下一页