关于面向对象的软件设计,高手请近(600分,如果答的好,一个人可全的)(300分)

  • 主题发起人 主题发起人 小乔
  • 开始时间 开始时间

小乔

Unregistered / Unconfirmed
GUEST, unregistred user!
[blue]关于面向对象的设计,结合与Delphi,我一直不是很明白,现有问题请教,请各位高手不吝赐教。
1、在用面向的方法设计软件时,应当注意的问题是什么,应当如何下手?
2、我们设计的对象如何对资料库信息进行读取和写入,怎么与TQuery等交互?
3、当用到统计或是信息输出(比如符合某一条件的信息,又或是报表等),如何在我们设计的对象中体现呢?
4、我们设计的对象如何与界面元素结合起来,比如信息的录入我们都是用Form,可是却保存到对象中,如何处理?
5、如何与螺旋软件过程结合?
6、如何与三层结构结合?
问了一大堆问题,望大家给小弟一个答复,对每一个答案,如果正确,都是50分,当然更重要的是大家可以共同探讨技术问题。谢谢各位。[/blue]
 
这个在很多书上都有,不过的在实践中去理解。
 
你的問題很不具體,我可以給你推薦幾本書,給你研究
1.深入淺出DELPHI 6 清華大學出版社
2.DELHI6數據庫開發 飛思科技產品研發中心
3.DELPHI 6 入門與提高 人民郵電出版社
 
這個東西三言兩語可是說不清。
可以寫一堆呢
 
说来话长
 
要看你的水平
 
其实!用在DELPHI中面向对象方法设计软件,并一定要把什么东西都有对象(OBJECT)来用
DELPHI来体现出来,如果什么问题都用对象来体现,我看设计出来的程序一定是只有原来设计者可以看懂和修改,其他人肯定是很难修改,因为勉强用对象来实现会在一定程度上违反了面向对象设计方法中的低耦合的原则。
其实面向对象方法设计在现在还是在不断的发展过程中,其在软件设计的需求分析阶段、分析阶段起到作用比较大,可以帮助软件设计者把现实生活中的问题抽象化并为计算机所理解。
 
我认为gdgzdelphi说的很没有道理,把一些操作封装到对象中,用接口进行访问,这其实正是降低了模块间的耦合性!
 
继承
封装
多态
 
天不怕,地不怕,就别人和我谈对象!
 
http://www.delphibbs.com/delphibbs/dispq.asp?lid=1951482
这个问题barton有深入的研究,去听听课吧。
 
确实不是几句话说得清楚的.经验是很重要的.设计类的继承关系真的类似设计数据库,没有相当的经验是做不好的.多写代码!
 
> 1、在用面向的方法设计软件时,应当注意的问题是什么,应当如何下手?
用OO的思想去设计软件,从软件的模块化下手,将软件的功能模块化。(参考MacroCantu的OOP20条规则)
> 2、我们设计的对象如何对资料库信息进行读取和写入,怎么与TQuery等交互?
可以设计一个专门负责数据库处理的类,一切对数据库的操作皆由该类处理。
eg. TDBManager = class
在TDBManager中定义一些操作接口供使用
> 3、当用到统计或是信息输出(比如符合某一条件的信息,又或是报表等),如何在我们设计的对象中体现呢?
同上,设计一个具有操作借口来提供操作
>4、我们设计的对象如何与界面元素结合起来,比如信息的录入我们都是用Form,可是却保存到对象中,如何处理?
将界面与功能分离,所有的界面操作都通过一个指定的类来操作数据。
> 5、如何与螺旋软件过程结合?
> 6、如何与三层结构结合?
拙见,见笑。
 
问题太大了,一个一个说
1、在用面向的方法设计软件时,应当注意的问题是什么,应当如何下手?
对已有代码的难以修改和不易重用想来大家都很有体会了,面向对象的目的在于使各个级别上的修改和重用变得更容易。所以在进行OOD的时候,最关键的就是在设计的时候不要太多的考虑实现——我觉得这是学习OOD时最难的一点,因为我们自然而然的就会在一开始做设计的时候就被功能实现吸引过去了。在开始设计时应当多考虑的是这个系统将来会怎样地被修改、怎样地被重用。
Alan Shalloway建议每个学习OO的人一开始就去学习设计模式,其实设计模式的精髓就是如何找到容易变化的地方,并将它包装成类。
转一段话:[blue]
gigix:我还有个问题。在OOD中,哪些原则是最重要的?
shalloway:我无法说哪些原则是"最重要"的,但是我可以列举出一些重要的原则。你应该把对象看成定义良好的责任;对象应该对自己负责;封装是某种形式的隐藏:隐藏数据、实现或者是类;让事物之间的耦合明确化(松耦合);每个方法做一件事、也只做一件事;类只包含相关的方法;尽量避免冗余。
[/blue]
以上shalloway说的各个原则应当就是OOD的注意要点了。
 
to plzw:你说的MacroCantu的OOP20条规则,就是写Mastering Delphi系列的那个MacroCantu吧,哪里可以看到[red]OOP20条规则[/red]?www.macrocantu.com我上不去
 
2、我们设计的对象如何对资料库信息进行读取和写入,怎么与TQuery等交互?
这个问题就像所有的面向对象设计问题一样,关键在于预测到可能要修改或扩展的地方,并不是说把所有的数据库操作封到一个类里就可以了。对于可能要修改的,把它封装起来,对于要扩展的,建立一个接口或者抽象类,然后由某个具体类来实现。
有一个实例如下,我参与开发的一个项目中,有多种数据报文需要保存到数据库,每种报文对应于1到多张库表。在这种情况下,考虑到以后可能会有新的数据报文要处理,所以我们在设计时,在每一个解析包里都有一个专门处理数据库操作的类,相当于一个proxy模式,把每个类的数据库操作封装在一个公用类里。如果是把所有类的数据库操作都放在一个类中实现,那么如果系统要增加或去除一个解析包,就必须对数据库操作的类作同步修改,这就是耦合。
但如果是一个数据库结构变化不大的库,可以考虑将所有的数据库操作封装到一个类里。
在具体的设计过程中不要拘泥于类,如果某种方法可以使代码清晰,修改简单而少有“副作用”,那么哪怕是非面向对象的方法,也是应该采用的
 
4、我们设计的对象如何与界面元素结合起来,比如信息的录入我们都是用Form,可是却保存到对象中,如何处理?
跳过一个,现讲这个问题。有一种大名鼎鼎的构架模式——MVC——大家可能听说过。在这种模式中,表示层和逻辑层做到了完美的脱离。我做过的一个论坛,用jsp+servlet+javabean实现的,其中jsp作web页面,用户通过jsp页面发出请求,服务器将请求交给相应的servlet,由servlet做业务处理(比如到数据库中查询),javabean则是数据实体,它有点像record,只有一些set和get方法,servlet将查到的记录转成javabean,再发给某一jsp页面,将结果显示给用户。(搞java的朋友可以研究一下JIVE的原码,里面有无数的模式)
在Delphi里,应当是建立一系列的业务逻辑类,数据层应当是一些实体类或者就是record,Form就是表示层。不过这样的话Delphi的优势——快速开发,尤其是数据感知——就发挥不出来了。所以一般来说,我只考虑把过于复杂的业务逻辑封装成类(比如一个ButtonClick事件里居然有3千多行的代码,就必须考虑用一个业务逻辑类来处理了)。而对于一些易变的部分,我也考虑把它做成一个类或者仅仅是一个procedure/function,这样容易修改。(其实并不一定要做成类,如果record或者procedure能够解决问题就不需要类了,不少设计模式都不是面向对象的)
borland买下了together,不知道以后delphi和together将如何结合,能够在不放弃VCL的优点的同时使建模变得更容易。
 
5、如何与螺旋软件过程结合?
这个可以看看UML和RUP之类的,我只翻过一点点,不敢乱说,可以到<软件工程>版去问问
6、如何与三层结构结合?
我还不知道如何用delphi作三层,我本来想仔细研究一下COM、DCOM和Corba的,但是后来因为工作的关系转到java了,结果就没看下去,连我买的都送人了,[:(]
 
我个人意见,仅供参考,主要是有一个很好的逻辑关系,其它运用的技术不是太大的问题,如果你的软件很大的话,建议用一些简单的技术,太复杂有可能带了很复杂的bug,到时候就有苦头吃了,呵呵,我深有体会了。
com,dcom等研究一下是非常必要的,但是要掌握非一朝一夕可以实现的了。
 
学习一下。
 
后退
顶部