DELPHI“迫害”了一帮程序员!(0分)

  • 主题发起人 主题发起人 Aloney
  • 开始时间 开始时间
那些被“迫害”的不过是一些自甘堕落的人,正如一个四肢健全的成年人,因为懒而不愿意劳动,
却要说社会在“迫害”他一样。
用OOP的方法写汇编的事我做过,我还实现一个类似Windows消息机制的东东,是很累,也很有趣,
但是很没效率,只是当时产品需要(那是一个TSR程序)。
我一向很反对用第三方控件,因为根据木桶原理,如果这个控件的质量不高,将严重影响你程序的质量,
特别是控件还没有源程序的情况,除非我能肯定这个控件的质量要比我写的程序高,并且用它可以大大改进我的程序,
而不只是界面上花俏而已。
我曾经也喜欢用Data-aware控件,认为用它效率高,但后来我认识到,它同时带来了性能下降和功能局限,
如果没有意识到这一点,而指责Delphi毫无道理可言,在很多时候Data-aware控件仅供入门学习。
至于Delphi的数据字典,的确很弱,并且依赖于Data-aware控件和BDE,用处不大,必要时还是要自已实现,
当然会比PB没效率,PB的数据字典是和DataWindow结合的,效率的确是数据库开发中最高的,
但DataWindow有多ugly,大家都知道。
所以,只知道堆砌控件,事事依赖开发工具,而不知道自已解决问题,在效率和其它要求之间权衡得失的人,
还是不要用DELPHI,让她少受一些无妄的责难,你们还是去用其它的工具,然后骂它们去。
 

还以为是什么东西,明知道是初学者的所为,又何来"迫害"?
"DELPHI只是前端的开发工具,并不是系统的开发工具,若用它来做系统恐怕还得深入的“研究”!"
什么是系统的开发工具?Delphi中会没有设计?哈哈!不喜欢Delphi的组件没关系,没有迫你用。
总是不明白,为什么初学者一定要将Delphi与数据库联系得这么紧?
 
水平太低,何必怨人,我最恨的delphi程序员在窗体上放一大堆的控件,那是水平太低的表现
至于数据库的连接,你可以自己用delphi写一个连接呀?你行吗?delphi可以嵌套汇编语言,
你说他不能做什么呢?delphi除了写与数据库有关的,还可以做很多别的呢,如果写以数据库
为中心的应用选delphi就是错误,懂吗?该选择power builder才对,比delphi快方便
 
我觉得pb那种一个数据窗口带着数据连接存放也比delphi放那个query或者table方便点,
搞得我的datamodule上几乎都没地方放query了。
 
呵呵,你用过dm么?
层次不是Borland给你的,是你自己建起来的。
Borland已经告诉你分层次了,你不分,怪谁?
你说的有的东西是对的,不否认,但是太偏激了,随着水平的提高你会认为自己的问题很幼稚。
 
为什么要放那么多Tquery控件,怪了!
 
工具本身固有的缺陷是其它方法难以弥补的,我在讨论DELPHI本身的缺点!
榔头可以订钉子,但用来拆墙恐怕是不太适合了,即便慢慢干也行!
 
再次关注一下,不同的时候有不同的想法。
一接触delphi觉得编程模式焕然一新,但过不了多久觉得自己是在做苦力。
后来再接触多一些,看vcl,也不错。自己写一些东西,挺好的。
 
触类旁通,没有一种完美无暇的语言,我学了好几种了,喜欢哪个用哪个就是.
 
Delphi易学难精,钻下去你就发现它不是你想的那么简单[:)]
 
首先、不利于系统层次的划分。大部分人把SQL语
句放入TQUERY控件中,这个做法使客户端和服务器产生了严重的偶合现象,程序
的升级、更新变的相当困难。
升级程序主要是升级SQL语句吗? :)
如是,这个问题也一定是在c/s结构中。
解决方法: 把SQL语句放到一个外部文件中。
严重偶合!? DataSource已经把这个问题解决了吧?如果是想通过有永久字段实现
Displyawidth, displayLabel的功能,建议你建个记录所有字段中英文对照的字典表
----------------------------------
其次,产生大量的控件。复杂的系统将导致你的窗体
上放满了数据库控件,管理相当复杂,而且容易弄错,编程复杂度直线上升。
尽量的使用Query来得到数据,适当分类的建立DataModule
-------------------------------------------------------
再次、它的编程思路“迫害”了不少人,以至于想用其它的开发工具显的无从下手,完全
忽略了程序设计的精髓,设计,DELPHI中没有设计,只有控件!
才学不久时我也认为:component=delphi。请问你学多久了?不过我还是佩服你用这个
主题发贴子。 事实上delphi也是有缺点的,没有完美的工具。
谁说delphi是用来设计的?设计在你脑子里,什么?没有。怪不得发了这样的贴子
------------------------------------------------------
 
又是一个伤和气的讨论,大家又何必呢?
过去这样的讨论很多呢!
 
我相信ALONEY朋友对使用DELPHI有较多的经验,也很同意他所说尺有所长,寸有所
短。但是,DELPHI确定是个好东东,即使他更是个IDE,而不是个好的设计工具,不
是有ROSE,PD,甚至MODELMAKER吗?
个人认为好的设计的实现,应与编码工具无关。
如果哪个DELPHI程序员窗体上乱放控件,好好地批评他。
我也有ALONEY相似的想法,请各位批评指正!我所说的通常应当理解为用DELPHI更倾向于这
样做,或者DELPHI的功能中更方便这样做。当然,很少的人会用更精妙的办法。
  使用目前广泛应用的软件开发工具如VC、VB、Delphi、Cbuilder等进行开发时,
“通常”以窗体为中心设计用户界面,并以窗体中控件的事件来组织应用逻辑的实现。
虽然这种开发模式(或软件体系结构)有可视化设计用户界面及自动建立事件机制
的好处,但也有一些不足之处。
  (1) 从软件体系结构来说,用户界面“通常”在程序中的,改变界面通常要重新
编译;同时用户界面的外观表现与实现的功能紧密偶合,即其外观的设计与功能
的实现不能方便地分开。应用功能也是硬编码在程序中的,虽然可以分布在多个
模块中实现,但也不方便为每个具体的应用功能生成一个单独的可执行单元。通
常要改变或增加一个功能,会影响到许多其它功能。上述二个因素,阻碍了软件
的复用,从而也影响了开发效率和可维护性。
  (2) 从软件开发过程来说,应用这种开发模式进行设计,要先做好比较详细
的需求分析,例如要详细到界面布局,具体每个功能的细节,然后才能着手进行
下一步的设计和编码。这种开发模式要求用户需求是静态的,确定后就不便改变。
在工程实践中,通常通过用合同等手段约束用户的需求更改。但用户需求的是很
难准确描述的,甚至只有最终使用到软件产品后,才能准确地确定到底需要什么。
用户的需求也是有一个迭代的、增量的演进过程。因此,这种开发模式使得软件
开发过程不能很好地适应用户需求的变更。
  (3) 从软件开发参与者来说,应用这种开发模式进行设计,通常程序员要全过
程参加软件的开发,从需求分析、总体设计到详细编码,包括数据结构的设计,界
面设计等等。一般主要分系统分析员和程序员二种角色,前者负责总体设计,后者
负责编码。理想的情况是划分更多的角色,使每种角色做相应专业的工作,例如数
据结构设计,界面设计,底层接口,各种具体应用功能。每种角色的工作相对是独
立的,与其他角色的工作间有简单而固定的接口,这显然可以提高工作效率并容易
保证工作的质量。而通常以窗体为中心的程序开发模式,不便于软件开发过程中角
色的划分。
 
论据不能充分证明论点吧!
 
有道理,现在我都不维护写的程序了,直接改教用户用SQL语句,:)
 
呵呵,强烈抗议高级语言惯坏了程序员,现在哪个程序员会懂得拨弄二进制开关输入机器语言程序?
 
呃, 看了此贴, 我倒, 乖乖龙的东, 我感觉自己被埋了. :)
各位大哥, 救命哪, 帮我刨刨土, 拉上一把…………
是不是现在就改学C呀? (差点就要哭爹叫娘了) :) :)
不过我也觉得, Delphi学着学着, 完全不象我刚学的时候认为的那么简单。
从许多文章上看到, Delphi编程也完全可以把控件撂开。(不过我还完全不是那块料)
我也想再加一门C备着, 但就怕画虎不成反类犬。 :)
个人认为, 抛开Delphi的VCL, 剩下的主要就是Pascal了, 应该说还不错。
我觉得是不是应该兼收并蓄, 取长补短呢?
讨论编程工具谁优谁劣, 似乎没什么吸引力了, 倒不如深入讨论一下编程工具
挖潜掘能的问题, 让人更能摩拳擦掌些。我等小弟也好跟着揩揩油。 :)
Delphi问题显然不少, 自己也遇到过许多 :( :(。
我想其他的编程工具也不见得少?
同意楼上的, 设计并不在编程工具上, 而是在脑袋里。
唉, 我等Delphi虫究竟应该怎样才好? 路在何方? God Save me?
 
我靠,你在哪里住?千万别给我留地址!:)
我认为只要能解决问题就OK了,无论你的语句怎么写,顺序怎么样!
 
delphi 虽然有很多控件,但并不是都很实用。
我们公司用到的有很多都是自己开发的而且很实用。
所以,delphi还是很不错的
 
靠 记事本(Win2000XP下的)是最好的开发工具。。。。。。。。
 
后退
顶部