一位同事因为设计的几个类搞了几十个public的成员，被经理指责得一无是处，大家评评理！(0分)

unit unit1;
....
var
form1: tform1;
gwdm:string;
implementation
....
procedure Tform1.formshow(Sender:tobject);
begin
query1.close;
query1.sql.clear;
query1.sql.add('select * from table_x where GWDM='+#39+GWDM+#39;
QUERY1.PREPARE;
QUERY1.OPEN;
end;
END.

UNIT UNIT2;
USES
。。。
UNIT1;
...
PROCEDURE GWDM_USE(CONST in_GWDM:STRING);
implementation
....
PROCEDURE GWDM_USE(CONST in_GWDM:STRING);
begin
form1:=tform1.create(application);
with form1 do
try
gwdm:=in_gwdm;
SHOWMODAL;
finally
free;
end;
end

end.

调用 gwdm_use('KRD');

这样的写法，是否是完全错误的（按照规范来看），

嘿嘿，居然帐号还在，那就说几句。

经理很垃圾，沟通和管理下属都有问题。老板面前是孙子，下属面前是老子。

楼上的,活都是干出来的,不是屁股放个屁就能完成的.
换了你来当经理,你行么?[][][]

行不行不是靠说的[]
我也不需要向你证明什么[]

你是那个经理吗？如果是，我还是那个态度。[]

这么多回帖，大家都谈出来很多自己在写程序过程中的困惑和创造，我觉得这是很好的事情，这里有些问题，甚至对面就是面
向对象的创立者，他也会想不出怎么回答的。所以，一切人身攻击的言论就不必再提了。

从类成员一直谈到属性，期间夹杂着对做人 RP 的讨论，都非常有意义。属性问题是谈得比较多的，我是从二个方面来看待的：

1. 属性的通俗意义：属性出现在一个类中，或者出现在一个接口描述中，我个人的观点倾向于不是封装所必须。这个观点在接
口描述中表述的话，可能会更清晰一些，因为在接口描述中，属性直接就是某个接口函数的“简写”。因此，我理解的属性的通
俗意义是“醒目”。意思是说，它的出现，便于用一个短词（或者等同于某数据成员的名字）来引用一个关键的数据成员（指类中的属性）。

2. Delphi 中的属性：也许我的理解有错误，但我始终认为 Delphi 最好的部分是 VCL 架构。在这个架构下，属性被赋予了一个
特殊的使命——运行时调度（Runtime Dispatch），这个名词是我杜撰的，意思是在运行时保留类型信息，在适当的时候从一种形
态还原到另一种形态，而要完成这个使命，属性必须出现在 published 字段（我们也可以使用 {$M+} 来做这个工作）。

在这样的情况下，不同的编写者，属性就会出现不同的命运：一位 runtime class library 的作者和另一位 Delphi-
Component library 的作者，虽然都在使用 Delphi，对属性的依赖是完全不同的。一旦这样的二位遇到一起的话，属性就会
成为他们无法逾越的鸿沟。

高手这么多,帮一下我,快死了...........


http://www.delphibbs.com/delphibbs/dispq.asp?lid=3905346

只要是经理,那个不是"老板面前是孙子，下属面前是老子"哦!
不当孙子怎么当爷,当爷之前,先去当孙子,我来教你做人!

SetHeight(GetHeight() + 10);
其实可以用一个更简单的方法代替:
IncHeight(10);
也比Height := Height + 10更简明;
尤如Inc()函数;

编程好比舞剑,有华山派,青城派之分,不同的门派对剑道的理解不同
而BOLAND的工程师好比铸剑的工匠,他们造出剑来要华山派,青城派
都能用才行.最后谁历害要盾谁能打败谁.所以里面保留了非结构化的
GOTO语句和各种编译开关,为各种写法在语法提供方便.

面向对象的方法也不一定是编程的唯一门派,对宇宙和世界的描述方法
也不一定是最终的.而且面向对象的方法有进化论的继承的理解在里面
而进化论现在也只是一种假说,而且更多的证据证明其就是一门伪科学.
在进化论思想指导下搞出来的面向对象的方法到最后也有可能被程序员
放弃.面向对象的方法如果来描述生物界,很多人可能以为是得天独厚,
然而生物的复杂远远超过面向对象的方法的小儿科.
面向对象给出所有生物一个祖先,TOBJECT,然后不断分枝,加属性,但是这
样并不一定符合造物主的思想.
我理解的生物界应该是全息的,就是每一个生物生就具有所有的属性,而
每个属性又具有整体的所有属性.推而广之,宇宙中每一个物体都具有宇宙
的形象,比如一个棍子它其实能变化成一个人,因为棍子里本身就有人体的所
有属性,比如孙悟空变成了一座庙,用面向对象来处理就不好搞了,是两个完全
不同的对象,最多其祖先都是TOBJECT,然而孙悟空变成的庙处处都是孙悟空的
对照属性,如他的舌头变成了菩萨,嘴变成了庙门,眼睛变成窗,然而就是尾巴
不好处理,于是他就把它变成一根旗杆.根据这种思想,可以设计一种新的编程
理论,就是不需要继承的对象方法.

由于对面向对象天生有成见,所以我到这里就止步了,仅能免强用面向过程的方法
编点程序.我觉得用单元照样能实现封装等思想.单元的发明不是安得什么思的,而
是PASCAL的创始人设计的叫模块,只是单元借用了他的一些思想.在PASCAL的创始
人设计的模块中,可以在一个函数内引用其它模块(单元),这一点,DELPHI现在都
作不到.PASCAL的创始人设计的模块其实是一种自顶向下的程序设计方法.上层不
考虑下层如何实现,下层提供上层的抽象层,下下下层又实下比它高一层的功能.
DELPHI为了PK VB ,把这种思想割靴适履,整个的结构就是完全违反了PASCAL创始人
的抽象层思路,我们在每个FORM的单元中的INTERFACE里都能看到USES WINDOWS
这些其实都是很龌龊的作法,USES WINDOWS其实在IMPLEMENTATION中都不能看到的
应该在所有层的最底层出现才对．
但是大家都满足于快速开发的方便,就不注重这些了.然而有些面向对象洁癖者,把
各种函数都搞成对象,还不停的加到TFORM1的方法中用,自我感觉面向对象了,有档
次了,可以在新手面前显摆了,其实这些代码包括DELPHI的源代码放到PASCAL创始人
的面前一样会被他扔到垃圾筒里.但是既然都这样了,DELPHI的开发者也不是神,当
时也是为了一心PK VB，所以在思路上也没有精雕，反正发布出来比ＶＢ上一个档
次，就算成功了．ＤＥＬＰＨＩ编起程来一个字快，但是由于这些天生的特点，结构
就有些散乱，除了那些从头来的不用ＶＣＬ的．

以上是个人观点．

换个角度谈这个问题：
第一是关于代码质量问题。
我对自己的最多评价就是不求甚解，不求精益求精，为什么呢？因为代码一是用来用的，不是用来看的，二是本来就不存在一个永恒的东西，实在没必要为这样的代码耗费太多精神。
（不关心代码质量并不包括不关心代码的错误，无错代码是程序员追求的第一目标，此外代码的可读性，代码的可维护性-最大避免代码的重复性也是必需遵循的原则）

第二是关于OO问题，个人感觉OO绝对不是目的，而只是手段。
对于数据为中心的类，但是又不能用RECORD，需要封装方法，这种PUBLIC变量有何不可呢？在C++里CLASS是默认PRIVATE，而STRUCT则默认是PUBLIC，而带成员函数的STRUCT的应用同样非常广泛。
写DELPHI的人，很容易把CLASS写得象COMPONENT，自己可能还觉得很好，其实这是DELPHI的糟粕：学习DELPHI的VCL作为DELPHI的OO入门恰恰是DELPHI的糟粕，滥用property就是其中之一，因为DELPHI的很多Property从CLASS本身而言就是脱裤子放屁，仅仅只是为了设计器能够认识。

我是新手，用Delphi 两年左右，如果直接在Public里面写变量的话，我觉得很恐慌，因为有些属性对外是只读的，有些是完全的。GetXXX, SetXXX,我看着觉得舒服。

注意看下面的代码，看清楚有多少问题、或者根本没有问题后，我们再来谈面向对象。

这段代码摘自随 Delphi 各个版本发布的 Borland 官方 Demos：ImagView 项目

procedure TImageForm.FileListBox1Click(Sender: TObject);
var
FileExt: string[4];
begin
FileExt := AnsiUpperCase(ExtractFileExt(FileListBox1.Filename));
if (FileExt = '.BMP') or (FileExt = '.ICO') or (FileExt = '.WMF') or
(FileExt = '.EMF') then
begin
Image1.Picture.LoadFromFile(FileListBox1.Filename);
Caption := FormCaption + ExtractFilename(FileListBox1.Filename);
if (FileExt = '.BMP') then
begin
Caption := Caption +
Format(' (%d x %d)', [Image1.Picture.Width, Image1.Picture.Height]);
ViewForm.Image1.Picture := Image1.Picture;
ViewForm.Caption := Caption;
if GlyphCheck.Checked then ViewAsGlyph(FileExt);
end
else
GlyphCheck.Checked := False;
if FileExt = '.ICO' then
begin
Icon := Image1.Picture.Icon;
ViewForm.Image1.Picture.Icon := Icon;
end;
if (FileExt = '.WMF') or (FileExt = '.EMF') then
ViewForm.Image1.Picture.Metafile := Image1.Picture.Metafile;
end;
end;

ViewForm.Image1.Picture := Image1.Picture;
ViewForm.Caption := Caption;
---------------------------------------------
ViewForm.Image1.Picture.Metafile := Image1.Picture.Metafile;
为了给他赋值就是setvalue，没办法，只能写了在其他人看来无用的代码,其实内部已经做了asisgen picture的过程，从面向对象来说，应该是一个action了
－－－－－－－－－－－－－－－－－－－－
Icon := Image1.Picture.Icon
ViewForm.Image1.Picture.Icon := Icon;
---------------------------------------------
这个地方看起来更乱，先把Image1.Picture.Icon赋值给form.icon，然后再重新复制给
viewform.image1。

通常情况下,在芸芸众生之中,爬得最高的人,基本上都有肯担当的习惯,从这个角度而言,错了就是错了,没有任何借口可言,找原因找解决办法都因该先从自身上首先开始,就算别人的态度不好,甚至恶劣,也要先检讨自己,努力提高自己是最重要的,而不因把问题推到别人或企业上.

to 地质灾害:
通常未经测试的代码总会有这样那样的BUG或者说屁存在了, 这应该不算什么大事, 其实我想表达的是 myvar: pinteger
漏写了一个字符, 不过如果你理解了我想要表达的意思的话, 那个代码的错误应该是可以忽略的。不过似乎很明显你只闻到了屁，就看不到其它了，呵呵。

高手继续，我学习

大家跑题了，呵呵
人家是要你们评理，不是要各位发表对DELPHI，OOP的看法呢

cpj7406：
我个人觉得，技术上有点问题是客观事实，但是经理和企业也有责任！
1）显然企业培训不足；2）显然工作安排失误。（也是迫于领导压力，我也不敢开口）
我还觉得有点小题大做。

我觉得第一点站不住，毕竟现在的企业不是培训学校，他希望的是成手，熟手，而不是新手。第二点我觉得经理可能确实有点失误，失误在于对人员的水平判断上有误差。
小题大做嘛，倒也不一定。该说还得说，只不过可以注意一点方式方法。不过从后来你的同事辞职来看，估计她本身确实有问题，经理可能有些恨铁不成钢了。

几十个public的数据成员，作为一个类来说，怎么也是有问题，一般的类，很少能有几十个数据成员的，何况public的数据成员。全部都是public的数据成员，类的封装确实无从谈起。让外部函数直接操作该类的几十个public的数据成员，确实给维护和扩展带来极大的风险和困难。这个经理的话是没错的。

呵呵,谢谢muhx 你给我面子,
我对这句话 :"楼上那些说不需要property的家伙我想也不会写出什么高质量的代码,就算能满足功能上的需求,代码看上去也是一团糟.给日后维护会带来不必要的麻烦." 是有点偏见了,纯属于个人看法,伤了某些人的自尊了,在此说声sorry .

我也曾维护一个系统 ,发现以前的同事完全在public 定义变量,导致public 的变量在不同的地方被赋与不合理的值,导致后来在不同的地方增加很多相同的if语句,给系统维护带来很大的麻烦.

我个人还是觉得使用property 是编程的一种良好的风格.清爽得一目了然.

DELPHI被你们搞成什么了

DELPHI就和敏捷开发一样秉承RAD的思想
什么软件设计，设计模式 让他见鬼去吧

我在此可长见识了.hehe