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

  • 主题发起人 主题发起人 cpj7406
  • 开始时间 开始时间
to dirk and jacket84:
我印象里面Delphi编译器会成编译的时候禁止对属性进行地址操作,以保证对象的封装性,但事实却正如二位指出的那样,似乎是件很奇妙的事情。我做了个简单的测试程序:
program a;

type
TClassA = class(TObject)
private
FVarA: string;
public
property VarA: string read FVarA;
end;

procedure test;
var
ca: TClassA;
p: ^String;
begin
ca:=TClassA.Create;
p:=@ca.VarA;
p^:='Hello, World!';
WriteLn(ca.VarA);
end;

begin
test;
end.

结果一个只读的属性,也可以是不只读的,只要我们直接对它的地址赋值就好了。我原以为是Delphi新引进的一个Bug,但是FreePascal下也可以运行通过……

但是为什么呢?
如果允许像上面一样操作只读属性的话,似乎可以做出很多奇奇怪怪的事情来。比如:
procedure TForm2.Button1Click(Sender: TObject);
var
list: TList;
pc: PInteger;
i: Integer;
begin
list:=TList.Create;
pc:=@list.Count;
pc^:=5;
list.Add(Self);
list.Free;
end;

各位有什么想法?
 
回去好好学习吧~
 
软件设计规划得好不好,要看最后运行的效果,要稳定,没有什么逻辑上的BUG漏洞。
从这个角度来看,内部是如何设计的都无所谓。就比如建筑,古代的建筑没有现代的
建筑计算和施工规划理论,在地震来时却表现得比现代建筑好。
有人说《传奇》的源代码写得很差,可是至少比国产的游戏稳定得多。就如QQ这样的
经常中途退出。无论里面怎么封装怎么面向对象,从效果看也是差。
 
to cpj7406;
对于你的怜香惜玉,我非常感动,你为什么不帮帮你的那位女同事MM看看代码呢?难道同事间就不能互相帮帮忙,对于那些经验不足的同事也是件好事,对于公司也是好事.

你可以让你那个同事MM有什么程序上的困难联系我,我尽能力会帮的;

其实我不觉得public和property之间有什么关系,对于实现方法也是个人习惯,一个公司写类的方法和习惯都不见得一样,最主要的是公司要有个专业型的领导来统一,谁也不是天生就会的.那个经理是不是以前也被别人这样对待过?心理有点不平衡.
 
“清新空气”朋友说的是,做为同事,我做得不够,内心也有歉意!

所在公司虽小,除了工资低点还算是规范齐全,项目管理、任务管理、Delphi/C#/Js/数据库的开发规范真真假假倒也是都有文档化制度,执行的怎样不敢说。

我也就是年龄比较大、个性不那么强、服从领导的安排、服从有用没用的制度、不那么较劲,因此平稳工作吧,毕竟要生活嘛。

年轻一些的同事(包括这位女同事),个性都比较强、对约束自己的规范及经理的“说教”基本上不太以为然,他(她)们看我可能有点像“奴才”。其实,奴才又怎样?公司经理在客户面前算什么?县长在市长面前算什么?市长在省长面前算什么?...唉,何必那么较劲呢,服从也是一种美德嘛(各位不要笑话)。

我那位女同事,经过此事一定会对她的人生有所帮助的!离职的时候她对我们经理说了许多愧疚的话、感伤落泪、说对不起经理对她的栽培和帮助。(这是事实啊,经理也是个程序员、一半是他(她)们的老师啊,我这是良心话)。
 
隨聊......

看來這個經理比較啃代碼,對面向對象開發比較透,Borland封裝的Vcl確實很美﹔對於這個員工,可能他還未能真正的進入OOP的樂園,所以才寫這樣的代碼,不過她能在這個時候能有人指點她,我們為她很幸運,如果她能很正面的看待這一些PK的話,她應該會有很大的進步。

其實我也是在看了Delphi2005的發布會時,有幸與見到李維,才開始體會到OOP的好處的,同時我也在工作中不斷的嘗試。

我個人認為,如果你的程序還是用面向過程的寫法的話,哪肯定是垃圾,因為你會沒完沒了的Beta。

type
TMyClass = Class
private
FmyProperty:integer;
function getmyProperty:integer;
procedure setmyProperty(value:integer);
public
property myProperty:integer read getmyProperty write setmyProperty
end;
 
牛人不少啊.
 
中国有很多公司都是这样,有意培养,但又不一定留得住人,我觉得经理应该比较手下的每一位同事,这样就可以经常给不同的同事看一些不同的代码实例,学习其中比较好的地方,这样员工会进步的更快,当然不愿意学的例外.
其实这位经理说的也不错,其实也我这样认为过,"Delphi"本身就是一位最好的Demo和老师;
多看看delphi的一些pas是有好处的;
对于楼主
"我也就是年龄比较大、个性不那么强、服从领导的安排、服从有用没用的制度、不那么较劲,因此平稳工作吧,毕竟要生活嘛。"
的处理,我非常理解,我也在过渡.
对于楼主有歉意,我觉得也不必要,错不在你,你也不可能总帮她查阅代码,最主要的是她自己要多问,多学.只是弄成如此的结果我觉得真是....无法形容.
不知道你们的经理会不会改变一下对员工的态度,不知道这位女同事会不会多用点功,做的更完善..
 
什么代码,要写多久,会让她引咎辞职,难道就不能自己加个班把程序改好吗?
难道什么需求都没有吗?
 
我想谈有两方面:面向对象思想里的封装和对经理的管理方法
1)
那位经理对员工如此的责备,应该说对类的封装有很严格的要求.
封装可以带来很多好处,提高代码的内聚力,降低耦合度,提高代码的安全性,提高代码的重用性,有利于将来对代码的维护成本...(我不必再此细说,呵呵)
在delphi类级别的封装中,对外接口的是public方法和published的事件和属性,而protectd和private成员则属于类的实现细节.
由于类本身设计就将对象的数据和对象的操作封装在一起,所以我们不能将类的数据成员视为普通变量.
这样delphi 就想出了property,通过property就可以让外部类安全访问类的数据成员了.
如通过在setXXX() 方法里面对私有数据成员作一些逻辑上的判断和限制,使其合法性,来保证数据成员的值的的正确,同时也保证代码的稳定性.
所以高质量的代码是需要封装的.
楼上那些说不需要property的家伙我想也不会写出什么高质量的代码,就算能满足功能上的需求,代码看上去也是一团糟.给日后维护会带来不必要的麻烦.

2)
经理对员工的指责,我觉得没什么,只要能够学到东西,让别人多说几句又何妨呢? 况且这也很正常,没什么大惊小怪的.
那个MM辞职了太可惜了,错过一次学习的机会.辞职就可以解脱了?
等学会了经理所说封装"封装"再走不迟.如果她还从事软件开发,用面向对象思想的话,以后还是会面对这样的问题.
这也说明那个MM没有团队精神,扔下烂摊子就走人,剩下的工作让新人接手,又得浪费时间.(项目经理最不想看到的)
代码写的规不规范,暂且不追究 ,最终看的是程序功能是否满足客户需求.不规范的代码可以后再修正嘛,毕竟大家都是一个团队,互相学习嘛.
那个经理干吗那么较劲,作为管理者此时应该对下属进行鼓励和指正,同时也要借此机会告诫其他同事以后不要犯同类的错误.营造一个轻松工作的气氛.
这是一个管理者必须要做的.
 
说的不错,
支持楼上所说!
 
MouseSoft说:我個人認為,如果你的程序還是用面向過程的寫法的話,哪肯定是垃圾,因為你會沒完沒了的Beta。

那你用的面向对向的C++或DELPHI也是面向過程的寫法写出来的程序,是不是也很垃圾啊。
 
同意LS

为了OO而OO,我觉得不必要。
OO也是一定约束下作的,不是所有的地方都要作成OO,我只认为简单,规范,整齐才是我想写的代码,虽然一开始起步的代码不会是那样。
 
to skyweb: 其实,按照面向对象来说,也就是按照borland的本意是想通过property read 和write的属性来控制一个类属性的读写,但delphi又不像java那样,java是不许直接操作内存地址的,net应该也是不可以的吧,所以自然会出现上面的这种能够通过修改内存地址来修改只读属性的bug,应该也不能算bug吧,只能算是一个特例吧,就像你用内存修改器来修改操作系统内存的值一样。

个人还是觉得,不能因为一个property来说谁写不出高质量的代码,操作系统内核的东西估计都不是面向对象的,java的人员也不用property,但是get set一样可以超好的实现OOP,
关键是设计。
 
实用才是硬道理!!
 
To hucejakie
"楼上那些说不需要property的家伙我想也不会写出什么高质量的代码,就算能满足功能上的需求,代码看上去也是一团糟.给日后维护会带来不必要的麻烦."

我对你这句话持保留意见
小雨哥说我的观点前后有些矛盾,其实我后面的补充还是给了像hucejakie这样的“高手”一些面子

现在我统一一下说法:
我认为,property就是Delphi的一块鸡肋
 
同意楼上的说法。perperty对delphi的面向对象开发来说,基本上是没有影响的。

个人觉得,property真正的意义应该在于delphi控件和窗体类的持久化和可视化设计,像属性的发布published是需要用到property,那样他才能跟ide中结合起来的,能够进行所见及所得的编辑,然后才会把这个属性保存在dfm文件中,也是这个property的存在造就了delphi即可以像VB那样RAD的开发,也可以实现像java那样的面向对象。
 
我认为属性是为了代码的阅读更加清楚明了,因为代码是给人看的。

Height := Height + 10;

SetHeight(GetHeight() + 10);

哪个更清楚明了?
也许仁者见仁,智者见智吧
 
不要怕被人说,谁都是在被说的环境中成长起来的,没被人说过的人根本就不是人!
坐到他这个位置上,无论说错说对,下面的人都要好好听听,用自己的知识去甄别错误,对的东西吸收,错的东西也不要轻易就反驳别人,经验相对多的人总是老师。
他是项目经理,他就要负责整个项目的实施,团队里他的责任是最大的,出了问题,不会具体找到你们,而是他!责任越大,说话难免不带着点”压力“!
个人觉的项目经理也是为她好,否则早就开掉了。一个人的能力大小在工作中很容易就能感受得到,按你这位女同事的设计水平,我相信你们项目经理平时不会不知道她的能力。既然能让她加入到这个团队中去锻炼成长,她应该感谢他!
你的这位同事经验较少,经历这么几次,我相信她会很快地成长起来的。
说一千道一万,还是工作方法的问题,说的直接点,就是不会学习。其实,像她这种情况第一件要干的事情就是找到类似”类“的设计原代码,看看人家是怎么设计的,类的设计门道很多,多看看,多借鉴下,对自己也是一种提高;第二件要干的事找本类设计手册来看看,找不到DELPHI的,可以看VCL,或找其他语言的,比如C#等,学学人家是如何设计类的;第三件就是请教有经验的人,让别人指点一二,在请教别人之前,最基本的东西先要掌握,否则没人愿意指导你。最基本的东西都没掌握,就喜欢问这问那的人往往是不受欢迎的!
。。。。。。。。。。。。。。
 
这件事跟人品没什么关系,说你项目经理人品如何如何,有些过头了!、
每个人技术上都会存在问题。说出来比不说出来要好。换一个另类性格的项目经理,会让其他人慢慢接手她的工作,到最后,只让她忙乎琐事,我相信她到那时候,会觉的更难受。只是一种假设,但现实生活中,这样的经理是存在的!
不说了,玩游戏去了。。。。。。。。。
 

Similar threads

S
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
D
回复
0
查看
1K
DelphiTeacher的专栏
D
D
回复
0
查看
2K
DelphiTeacher的专栏
D
后退
顶部