一点个人意见:期待Delphi所应具有的以下几个基本特征(欢迎讨论,都有分啊) (100分)

韧峰

Unregistered / Unconfirmed
GUEST, unregistred user!
本人以前使用FORTRAN进行完全过程化的程序设计,自去年转而使用Delphi进行面向对象程序设计以来,发现编程的天空骤然扩展了许多。面向对象的程序设计方案较之模块化的程序设计思想更好的实现了算法功能的封装及继承,同时Object Pascall语言自身的优雅,Delphi快速集成开发环境的优越性让我感觉到原来编程也有如此的艺术体验。
由于本人转向面向对象程序设计时间太短,对于面向对象概念本身,对于Delphi和Object Pascal语言都不是非常熟悉,因此以下的一些个人的观点可能非常肤浅,请各位大侠指出和包含。
在我个人使用Delphi进行程序设计的时候,有以下几点让我觉得不太方便的:
第一、关于自定义运算符或者运算符的重载问题。
Delphi中没有运算符重载的功能,这是个很大的缺陷。由于本人编程的数据对象完全面向复数,而Delphi不提供复数类新,自定义的复数类所有的运算只能直接调用函数实现,这对于复杂的表达式就显得非常繁琐而且不易于维护。
重载是一个方面,自定义是另一个方面。有些运算是基本运算符中所不包含的,譬如说矩阵的逆和转置,我希望能够自定义出一个新的运算符。这方面Delphi不支持。
对于以上的功能,目前还属于过程化程序设计的Fortran语言却支持良好。对于语言语法本身而言,实现对这方面功能的支持应该不是什么非常困难的事情。不知道Object Pascal中为什么不扩展。
第二、类中的模块化。
这是从程序的可读性和易维护方面来说的。在一个功能很强的庞大的类中,类属方法和函数本身也存在模块化的问题。我希望几个相关的函数和过程能够写在一起,在这些方法实现代码中也一样,写在一个连续的“模块”中。Delphi将类声明和实现代码分开,方便了阅读和维护,但是实现部分的代码却很乱,尽管Delphi提供了相关的功能让你能较快地找到相应的代码,但我觉得还是不太方便。有时候我只需要打印部分相关的源码,这就显得极不方便。因此,我希望类中能够再度“模块化”,积累的明可以如下:
TMyClass=Class
Private
Module1:
fx1,...,fXn:Double;
Procedure ...
function ...
Module2:
...
Module3:
...
Protected
Module1:
....
Module2:
...
Module3:
...

Public
Module1:
....
Module2:
...
Module3:
...
Published
Module1:
....
Module2:
...
Module3:
...
End;
在实现中,编译器自动将相关源码统一集成在一个相应的模块内。(哈哈,现在Delphi这方面做的确实不好,类的相关源码都没有写在一起)。
第三、关于提供可选特征( Option Attribute)的建议
封装是面向对象的目标和成就之一。然而,在我的编程过程中,我希望还能有一种“可选特征”。这种特征(Attribute)可以设为一种枚举变量,其值为Private,Protected,Public,Published的一种。因为在程序设计中,经常遇到这样的现象:由的数据对象一开始不允许访问,而在其他数据对象进行了某种操作以后才可以进行访问。例如我要进行曲线拟合,必须在已知的拟合数据已经赋值的情况下方可进行,否则就会引起错误。将拟合方法赋予“可选特征”,一开始其值为私有的(Private),在拟合数据赋值后再将其设为共用的(Public),这样封装起来的类数据安全性更好,而且也可能,更容易调试和维护。
以上只是我的一些拙见,大侠们尽管批评指教,不用客气。
 
不错, 我一直觉得Delphi不能像C++那样支持运算符重载很不方便, 应该改进.
 
既然这样,为什么不用C++呢?
 
呵呵,C++当然有C++的缺点,虽然他可以重载运算符。后面两个特征他也是没有没有的。
C++中没有Property,因此C++的封装估计不会比Object Pascal更好。
 
还有一点
Published是设计期间可见的属性难道Published约束性一定要大于等于Public??
例如:
设计期间在窗体上放一个按钮,在Delphi中这个按钮自动被设为Published元素
难道我不可以设置私有的,在设计其可见的元素吗?
干吗非要其他可访问本窗体的地方都可以访问这个按钮。

看看.net的设计期间属性,可选择是公有私有友元受保护等,我觉得值得借鉴。
 
>>关于提供可选特征( Option Attribute)

可选特征是可以定制的,自己定制类型吧
请不要要求一个软件是万能的, 如果你从VB,PD,VFP等转来,
你会欣喜喊叫,原来自己的想到的工具和功能,Delphi就有,
 
我觉得delphi的指针还应该加强。
 
回复wr960204
Publisher中的元素是要产生RTTI的,而Public中的不产生。
你当然可以将TButton放在私有里面,
只不过你要自己编代码Create、给Parent赋值以及Free而已,
 
复数计算功能可以用第三方控件实现
 
//第一、关于自定义运算符或者运算符的重载问题。
可以探讨。
//第二、类中的模块化。
意义不大,可以多写点注释,或者用过程内部方法.

//第三、关于提供可选特征( Option Attribute)的建议
没有必要。完全可以通过相应的方法去访问内部数据,
访问规则在方法中给出,而不是动态改变访问等级。
该建议将破坏于程序的封装,也将是使程序无法得到编译
器的检查与支持。 本人表示反对。
 
第一、类中模块化不是多写点注释就能解决问题的,也和过程内部方法不同。过程内部方法外部不能调用
这显然不符合我的要求。如果你编过上万行的源码,就能体会到其必要性。比如说一批待处理数据有各种
不同的处理方法,而一种处理方法中又有不同的表现形式,每一种表现形式中又分不同的步骤。这样,对于
每一种处理方法至少可以写成一个模块,而不能用一个过程中加在过程内方法来完成。这不符合结构化原则。
更重要的是,我们在编制大的程序时,一个类的某个方面的功能不是一开始就想到了,都是按次序完成的,
我们往往在使用了一段时间以后发现需要添加新的内容。而这些新的内容又往往和原程序某一部分有联系,
而由Delphi目前的功能看来,只能手动寻找实现该项功能的源码所在处,否则只能无序的添加,源码结构很
是混乱。尤其是一个单元中若有多个类,每个类的实现部分都交杂在一起,实在与Delphi Pascal 的优雅不
相称!!
关于可选特征(应该是Optional Attribute),我觉得是有意义的。这不是提供某种功能,而是带来某种方便。
这里所讨论的出发点就是这个:怎样让大家用起来更舒服。从功能上讲,面向对象的语言并不比过程化的语言
强,面向对象带来的是一种不同的实现方式而不是所能实现的功能。可选特征在编译上可能存在一些问题,但
如果实现,对于封装毫无疑问是有好处的。当然我们自己可以定制类似的功能,在程序中设定各种开关,但有一种
官方的统一的标准来做这件事可能更好一些。这就像异常处理一样,用逻辑判断同样能实现,但是用Try...Except更
人性化一些。而且我还希望有Try...Except...Finally,虽然这也可以用嵌套的方式实现。
 
//类中的模块化问题。
我们自己的写的类库再大,估计也不会比VCL复杂。
既然想引入类内模块是想把个“相关的函数和过程能够写在一起”。
原来的设计在“高聚能,低偶合”方面,是否还有提高的余地。
那为什么不把这些“个相关的函数和过程能够写在一起”写成另一个类
或者interface呢。现有的class和interface难道已经不能负担起
" Module1:"所期望的功能吗?
至于声明与实现分离的问题,可以利用一些java的
规则,一个文件只写一个类,如果觉得这样有必要。IDE本身当然可以
提供一些便利,todolist就是个很好的例子。

//关于可选特征
首先我还是看不出,这项建议的必要性。从建议者的表述来看
"将拟合方法赋予“可选特征”,一开始其值为私有的(Private),
在拟合数据赋值后再将其设为共用的(Public)"
我理解为在程序的runtime时期,可以改变存取。
我有必要指出在目前的主流语言的访问属性级别都是在编译时期就确定的,
在运行时是无法改变的。如果能改变,那这些访问属性级别还有什么意义。
“封装”就是让外界视封装体内部为"黑箱",以降低各子系统偶合程度。
如果“封装”可以在运行时动态改变,那就是不封装。
A条件,a可以访问b. B条件a不可访问b。 那a在访问前,需不需要判断条件呢?
实在看不出对"封装"有什么好处。

对于过程设计,与OO设计的问题。引用《代码大全》中文电子版P513中一句话
“软件设计和编码的主要目标是克服复杂性。许多编程风格的目的也就是降低
复杂性。对程序员来说,降低复杂性是一个很关键的问题。”
其他也就不多说了。
 
to tuti:
关于类中模块化问题:
你的论据在很多方面有问题。
关于类中的模块化
第一:Class和Interface可以实现模块的功能,我从来没有
说过不能。事实上,要实现这样的功能并不很复杂,不需要用到Interface这般抽象的东西。
事实上,因为我接触Delphi时间很短,并不知道如何使用Interface。而我也知道,我所要
求的也不需要更高层的知识。
第二:VCL不是一个类,而是有许许多多类构成的集成体。这一点不能语类的复杂程度相类比。
我说过了,现在面向对象的所有功能过程化语言的C都能实现(因为操作系统使用C写的),
按你的观点,既然C已经可以负担得起所有面向对象语言所有的功能,为什么还要发展面向
对象技术?你自己后面也说这是为了方面和安全。既然如此,为什么“Class和Interface”可以
负担得起我的要求就不需要发展新的技术呢?
第三、每个类一个单元,就不能实现单元级的封装,也就是说,类似C++中友元的功能就无法
实现。
第四、纵然一个类一个单元,也常常会出现混乱的时候。一个软件中都有一个主窗体,也就是
一个窗体类。在这个主窗体中要进行许许多多的操作。比如说每个主菜单项基本上是实现类似的
功能的有时候弹出菜单也实现类似的功能,但并不相同。这些方法的实现代码是否应该写在一起?
而目前,是乱套的。所以我经常需要将这些功能相关的方法的实现代码手动的移到一起去。
关于可选特征(Optinal Attribute)
第一:你没有弄清楚我的意思。我的意思是可选特征(Optional)是一个与Private等平级的
特征(我使用“特征”而非“属性”来描述“Attribute”,因为Delphi中“属性”应为
“Property”专用)。你原有的声明为Private/Protected/Public/Published特征的方法和数据
是无法更改的。也就是说我并不更改Delphi原有的封装特性,如果你不是用“Optional”。只有
对那些需要这样做的数据进行可选操作。即类的声明为:
Ta=Class(Tb)
Private
...
Protected
...
Public
...
Published
...
Optional
...
End;
只有声明在Optional中方法和字段才有可能具有可选特征的功能。因此这并不违背OO的原则。编译的时候
确实存在一些问题,但我相信这是肯定可以实现的。因为最开始动态数组的实现也为很多人不理解,但现在
不也是很正常的事情吗?我的一个构想是:Optional区所有的方法和字段都是可“访问”的,但是,当访问
时如果其中的某个方法其可选特征量为私有的,则出现统一处理的异常:“该可选特征量为私有的,目前不
能访问。”从而避免误操作而引起程序的崩溃,同时也清楚异常的原因,便于程序的维护和检查。

 
接受答案了。
 
也许面向对象的思想需要改进了,对象之间的耦合并经不是很容易的事
 
需要改进的是自己的认识,没搞清楚什么是面向对象前,
不要奢谈什么面向对象的改进。

《STL 源码剖析》中文版中,候捷提到"相对于STL源码而言,99.99%的人
写的代码都只是些三流代码,所以我们需要向大师学习"。

最近在看《设计模式》和《Effective Java》觉得要用好面向对象的思想
有很多精妙之处,并不是如搞一棵继承树那样显而易见,而需要反复研究
与体会。 顺便说一句,设计模式的学习,我推荐 http://www.jdon.com/。
那里的站长: 板桥里人(banq) 自己写的相关文章,可要比原书容易
理解多了。

虽然 保持健康的怀疑态度是一个好习惯。但我断言 99.9%的人并不能
有效的去谈论面向对象改进之类的话题。

 
to Tuti
第一、从你的回贴中,看到你对面向对象的理解其实很浅。
第二、你好像从未开发过超过一万行以上的程序,你的言行只是纸上谈兵
所以你不要在那里做那种大家式的评论了
 

Similar threads

回复
0
查看
679
不得闲
S
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
950
SUNSTONE的Delphi笔记
S
顶部