如何挣脱Delphi的束缚---也谈设计模式(0分)

  • 主题发起人 主题发起人 zdr
  • 开始时间 开始时间
Z

zdr

Unregistered / Unconfirmed
GUEST, unregistred user!
用Delphi编程，工具的设计者实际上提供了一整套“设计模式”---从设计模式的语
意来讲，如每本入门书都会举这么一个例子：
数据库编程？建一个Form,其上放一个Table、DataSource,设置别名，表名...放一
Dbgid、DbNavigqator,设置...,然后运行...，如要进一步控制程序，可进一步设定各
组件的属性，在事件中填一你的代码！
我敢肯定，我们中的很多人都是看了诸如此类的例子开始迷上Delphi。于是编程时不
约而同地重复这一“设计模式”。但是随着程序的复杂性增强，很难再管得住那些埋入的
地雷---事件中的代码、众多控件的属性。
我想让大家谈一谈，如何既能利用Delphi的RAD的固有优点，又可以摆脱上述“俗套”。
 
说吧
 
zdr
能说的清楚些么？我感受不到地雷！
 
Delphi 设计者为程序的设计者提供了一个很低的进入门槛，如我提出问题所说的那样。她
不要求程序设计者具备面向对象知识就可以设计程序，如我说的事件中填入代码，虽然其架
构是完全的面向对象的。因为VCL是封装的如此之好，所以可以完全感觉不到你在对一大堆
复杂的类在进行操作。这样的话，很容易使一般的Delphi使用者考虑问题时不从面向对象出
发，而把注意力集中在完成具体功能的代码上，因为这样也能完成程序功能，而且更容易实
现。但是这些镶入的代码分布面广了后，对程序后续的维护是不是带来麻烦。设想一下，在
某个事件中调用了一个自己写的函数，该函数又用到了某个组件的属性...等等。这些就是地
雷。我的本意是，是否有一种更好的方法，既能有效地利用Delphi作为一个优秀的工具提供
给我们的各种便利，又能避免上述的毛病。对不起大家了，这实际上是一个很难说得清楚的
问题，但是我很想知道。
 
Delphi 提供了不少的模板，能否運用的好這個主要是靠自己去總結了。
Delphi 相對於VC 來説已經不知道省了多少的麻煩，地雷不太會有的，就算有了也能夠
很快的找到的。
 
身有同感！没法
 
这个不能怪Delphi吧！只能说我们错误的使用了这个工具！
 
做好设计，在delphi类的基础上建立自己的类（最好形成类库），反正就是
软件工程、设计模式的那一套，主要是分析设计规划的人要有经验。每个人
都有自己的办法，有一些相似的，也有不同的地方，在于自己的体会。
 
我的做法把业务处理代码用类封装来封装，在事件中通过调用业务类的成员方法来实现，
通过成员方法的参数传递来实现类和界面的数据交换；
 
to taoahiyu
不知仔细看过Delphi的手册没有，实际上Delphi提供两种编程途径：一，对于一般的程序开
发者，利用已有的控件完成程序的编写，于是就引出我说的“毛病”，二，对于一些高手，
可以开发组件，供一般程序开发者使用，以达到“软件重用”的目的。注意我说的是组件，
而不一般意义上的类，写个类容易，写个组件可不那么容易。可见也不是“我们错误的使用了
这个工具”。当我们往Form上放了若干组件之后，这些组件如何协调一起工作呢？通过事件！
通过往事件量填代码来完成组件之间的交互。我有点固执，请见谅。
to other
如何设计自已的类，使之能和VCL中那些伟大的组件一起协调工作，又不丢失Delphi
提供给我们的便利。如：有人建议对于数据库中的每一张表（可视为一个无方法的类），
重新包装为一个企业物件（也就是一个类）并同时加上对表的操作作为企业物件的方法，
可Delphi设计者提供的现成做法是，用一个Table来引用一张表，同时也就提供了对被
引用的表的众多操作。每张表都表示成一个企业物件，如果有一百张表，那需要多少
工作量？如果表与表之间有主从关系？更绝的是如果是三层结构，难道客户端和中间
层都定义一个相同的企业物件？我对此十分不清楚。Delphi中的组件设计者，对于一类
问题的解决，提供了一系列的组件，可以说是一个完整的解决方案，但同时也带来一些
问题。如何权衡取舍，希望大家教我。
 
你完全也可以用VC＋＋那样用DELPHI呀
要是真的都这么用的，我们还会用DELPHI吗
当然也可以在两者中间的那种方法，就是结合使用呀
可以自己做控件，定义类，而DELPHI对类的良好封装正是我们想要的呀，难道不是吗？
 
学了Delphi后，再去学VC,这样就会对Delphi有了新的认识了
 
zdr的困扰确实也是个问题。关注！
 
to zdr:
表多了，关系复杂了，可以搞个persistence layer嘛
 
Delphi的实质是objectpascal，在设计过程中可以采用c/s,那样是无法避免结构不清晰的，
采用组件方式会出现维护上的麻烦。
我觉得用接口来处理这个问题比较好，采用三层结构com编程处理，可以将显示、算法和
数据结构分离。
 
过来听课
gordon_two,我水平低，看不出你说的方法是如何产生效果的，具体再说说好吗：）
 
同意gordon_two看法，我现在就是这样做的。
 
To zdr:
因为现在地数据库主流为关系数据库，其模型为ER模型，与OO很难相容。OO的目的是
更好的抽象现实问题。所以在对象数据库流行以前我们只能用OO的思想设计应用逻辑，
设计组件，用关系数据库解决数据库问题。
 
http://www.sunistudio.com/nicrosoft/viewpoint.htm
 
您必须登录或注册才可回复。

Similar threads

S
[教程]使用 ZAsyncInvoker 进行异步编程教程之二：ZAsyncInvoker 解决了什么问题
回复
0
查看
698
swish
S
X
使用kbmmw中的随机数替换delphi 10.3 自带的随机数 - xalion
回复
0
查看
721
xalion
X
不
关于在Delphi中链接VC的obj文件（XE2以上版本） - 不得闲
回复
0
查看
937
不得闲
不
S
[译]RAD Studio 10.4 新变化：面向控件的 VCL 样式管理
回复
0
查看
2K
swish
S
S
[教程]在 Delphi 中调用 .Net 的 DLL
回复
0
查看
1K
swish
S
后退
顶部