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

C

cpj7406

Unregistered / Unconfirmed
GUEST, unregistred user!
一位同事因为设计的几个类搞了几十个public的成员,被经理指责得一无是处,大家评评理!

经理说:“你这些类,成员都是公开的,给维护和扩展带来极大的风险和困难!”

同事说:“外部需要访问它们呀,不公开我怎么办?”

经理说:“你居然会这么说,属性是干什么的?不会看看人家 Borland 的源代码?随便找本面向对象的书,前 50 页就会有人告诉你如何封装、如何不直接暴露成员,搞了 1 年半的 Delphi,我觉得你就是一个幼儿园的水平...”(更多难听的话就略去了)

同事无语......(我估计心中有话,但是迫于领导压力不敢开口了)

这位同事是个女同志。

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

大家给评评理!
 
W

wpy020327

Unregistered / Unconfirmed
GUEST, unregistred user!
哪个不是从不会到会,从生疏到熟练的?
这个经理做法实在有点过份。
 
W

wsy539

Unregistered / Unconfirmed
GUEST, unregistred user!
在困难中成长
 

无欲则刚

Unregistered / Unconfirmed
GUEST, unregistred user!
你们经理软件工程看多了,诚然,设计不好是对后期维护有影响,但你要看你做的软件的大小和存活周期、空间有多长多大,如果仅仅是个小项目,给几个客户用,代码不用这么精雕细琢,那样更浪费时间,面向对象是很好,但不是普遍适用的,以前我设计系统,浪费了大量时间,后来,软件做出来,就没再动过,还不如直接编码来得舒服。如果大型项目,多人合作,那就需要好好设计设计了。
 

菜鸟黄

Unregistered / Unconfirmed
GUEST, unregistred user!
这种能力,这个企业都招进,这个老板是脑子进水了..呵呵~
朋友,要得到别人的尊重,首先就是要强大起来.
 

不能没有你

Unregistered / Unconfirmed
GUEST, unregistred user!
无语,
现在的程序员确实是水
经理更烂
 
R

roadexplorer

Unregistered / Unconfirmed
GUEST, unregistred user!
两人都不懂编程序
 

郭玉梁

Unregistered / Unconfirmed
GUEST, unregistred user!
我就搞不懂了
public和property有必然联系吗?
简单评价一下,女孩最多就是程序上经验不足,那个所谓的经理,就是人品问题了
 
B

bemed

Unregistered / Unconfirmed
GUEST, unregistred user!
楼主的经理上不上大富翁的?
楼主一定是迫于领导压力,不敢当面说,想通过大富翁来告诉你经理他做得不对的吧?[:D]
 
D

danng

Unregistered / Unconfirmed
GUEST, unregistred user!
让我说,你们的经理说的没错,他帮你们指明了更好的方向。
只是他跟你们沟通的方式不好罢了,如果他心平气和的跟你说这些,我相信你会觉得他很了不起,愿意分赏知识。
 

小雨哥

Unregistered / Unconfirmed
GUEST, unregistred user!
一个类的成员有二种,一种叫做函数成员,一种叫做数据成员。

在 public 段中,允许出现函数成员,尽量避免出现数据成员。如果上述所指的成员是数据成员,那么,不论到
哪里,被人“教育”一顿只是迟早的事。

既然 public 段不提倡出现数据成员,那么编译器就应该指出这样的问题。这是某个语言社区有人提出的意见。
他认为,只要编译器没有禁止代码应该如何写,代码本身可以没有任何约束。这个观点无疑具有鲜明的八十后
态度。没错的,如果只是个人写代码,完全可以按照这样的思维,我非常同意,并表示最大程度的鼓励,前提
是“你只是写给自己看,并且你仅仅为自己写代码”。假如你是在团队里写代码,或者,你写的代码打算被别
人利用(或看懂),那么我的观点你最好不要这么干,这不仅仅是为了让你避免被“再教育”,更重要的是
考虑到最终产品的质量。

很多事情本身并没有特别需要坚持或者放弃的内在原因,public 不要出现数据成员,并不能保证代码质量的
最终结果,函数里一样可以忽略必要的判断和限制,导致出现更多陷阱的代码。但,如果连public 段中不要出
现数据成员都不能保证,那么,您的代码基本上要额外地为您配备一位代码审核者,更为了看懂您的代码,
这位代码审核者应该比您有更高的水平和薪酬。既然有了这样的一位,那,为什么还要您来写代码呢?没有一
个企业或者团队会如此不惜代价来为你创造这样的环境的吧——边上有人提醒我说:“除非是他爹开的” :)
 
R

Roseking

Unregistered / Unconfirmed
GUEST, unregistred user!
关键是,一年前,这位同事水平如何,如果一年后水平还是如此,说明她不过是混日子罢了.很多程序员号称N年经验,其实有些不过是在堆彻工作时间. 那位经理应该领导水平不乍的,也可能到了忍无可忍的地步了吧[:)]

在public出现的数据成员应该尽量用property封装,如果这已经成了团队的共识,那么破坏这种规则的人,肯定会被K.因为他把坏习惯带进来了.
 
W

wpy020327

Unregistered / Unconfirmed
GUEST, unregistred user!
因为类是高度抽象出来的,与系统的架构等方面联系紧密,
所以类的编写本来就需要由技术相对好些的人来做的,而技术差点的一般就是使用一下类,
这个经理的工作安排是有点问题。
 
C

cpj7406

Unregistered / Unconfirmed
GUEST, unregistred user!
太谢谢大家的积极参于和评论了!

我介绍时遗漏说明了一点,我同事被指责的原因确实是公开了几十个“数据成员”,不是“函数成员”。

经理喜欢拿 Borland 开放的源代码来做范例,整天喋喋不休让人多阅读、多练习,我挺赞同他去教书好了,做什么经理呀?做经理,他那套对付“死”的软件的方法来对付“活”的人,教条、刻板、无趣!

人家都说“快乐编程”,在他手下感觉更有“工业化”的味道,快乐无存!
 
0

007vivi

Unregistered / Unconfirmed
GUEST, unregistred user!
经验不足,慢慢来吧,要能忍受,这点气都受不了,以后你怎么办呢>?现在的孩子,一点气都受不了. 也真难为他们了,
 
G

guanrui

Unregistered / Unconfirmed
GUEST, unregistred user!
呵呵 前辈们 说的我好惭愧.... 其实我自己设计的类 数据成员 一般都是公开的 写属性太麻烦了 一个成员带2个方法 以后一定改正.... 受教了...
 
T

tseug

Unregistered / Unconfirmed
GUEST, unregistred user!
我觉得这个经理还可以,至少当面指出来了,如果当面不说,背后直接下个评价说这个程序员能力不行,那她死都不知道怎么死的。

客观地说,1年半的时间如果上点心也不至于这样,经理说的没错,别人我不知道,我学Delphi1.0时可没那么多资料,只能看代码和帮助

不知道这个公司规模怎样,指着公司的培训来发展,呵呵

不管做什么,如果你改变不了现状,就只能去适应,否则,只有被淘汰
 

小雨哥

Unregistered / Unconfirmed
GUEST, unregistred user!
噢。我都漏看了,这家伙已经“搞了 1 年半的...”。忽悠到手了这一年半来的工资,遭这点罪其实也是很合算了,偷着乐吧。

可以唯一肯定,不直接开放数据成员,表现的可不仅是“要用属性去包装”。其他的就不用说了,多说无益,崇尚个性的年代,
女人越脱越光,男人越穿越多,爱怎么就怎么,很好、很强大,再加上还有人给工资,简直爽歪歪啦。请问是哪家公司啊,羡慕ing~~
 

活化石

Unregistered / Unconfirmed
GUEST, unregistred user!
骨子里,无非是杀鸡难猴看.这不过是,一种技术人员树立权威的作法.凡事不要看表象。
 

Similar threads

S
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
D
回复
0
查看
863
DelphiTeacher的专栏
D
D
回复
0
查看
2K
DelphiTeacher的专栏
D
顶部