发现一个奇怪的问题(1分)

  • 主题发起人 easemind
  • 开始时间
E

easemind

Unregistered / Unconfirmed
GUEST, unregistred user!
虽然面向对象编程离我们很近。但是很少能亲身用到。
比如form button, 控件 。 都是面向对象的。
但是在我们的程序中体现了多少
我们更多用的是继承。 比如 delphi的form ,看一看代码。是面向对象的。
问题是这些代码不是我们生成的。 我们更多的是在过程里填写代码。
所以我的理解是 是我们虽然用的是面向对象工具,但骨子里还是面向过程的。
不知道大家什么想法。
 
另外一点,更多是在表现(界面是一个例子)用到面向对象。而且问题或者软件设计的本身
用的不是oop. 如果谁使用绝对的面向对象 能不能提供一个具体实例?
 
不知道为什么没有人回应? 我觉得这个问题很尖锐。我也很困惑。
我看了很多别人的程序,还有自己写的程序。 还没有见过真正体现面向对象的思想在应用。
这个问题还不严重?不值得思考???? 如果去掉界面和很多表面的东西。
纯粹的个人编程思想里面有谁在用面向对象编程。 谢谢。 请大家考虑一下
工具是面向对象的不代表你做的事情和分析方法是面向对象的。
我可能说的不是很清楚,我认为大概意思大家也明白。
 
其实只要你看过有关体系结构方面的书,你就会认识到对象无所不在,计算机的世界其实和我们
生活的世界一样,由对象组成。每个对象之间彼此联系,共同完成某项任务。对象以接口的
方式供外界访问,对象可以以ocx,dll等等方式存在,其实系统的任何东西你都可以看作对象
对象一多就会乱,就要有东西来统一它们,这就是COM。windows2000等系统其实不是用某种
面向对象的语言编写的,微软下一代的系统则会是真正的面向对象。个人认为面向对象指不过
是一种思维方式,也许人们认为编程的思维方式应该和认识世界的方式一样。
比如form button等等控件无处不体现了面向对象的观点,要创建一个form或button,好,可以
从COM中创建它们的实例。建议你看一下COM本质论。
 
多学点java或c++的非delphi程序语言,对你本身也是一种促进,对编程思想是一种提升,
不能说做delphi 就必须学delphi,时间长了,发现并非语言本身的问题。在于编程思想的问题。
 
同意zhuzhenyu, 的看法。
╭══╮
╭╯ΘΘ║
╰⊙═⊙╯。oо○看啦~~~~~~,我给你送月饼来了!
 
>>我看了很多别人的程序,还有自己写的程序。 还没有见过真正体现面向对象的思想在应用。
>> 这个问题还不严重?不值得思考???? 如果去掉界面和很多表面的东西。
>>纯粹的个人编程思想里面有谁在用面向对象编程
VCL就是一个采用面向对象思想的一个很好的体系架构,你有没有看看,
 
同意楼上的。
 
我觉得easemind的说法有点偏见
你在过程中填写代码
但是你不是在写以前那种纯代码啊
你是在写某一对象的某一事件的代码啊
你能在DELPHI中写出不属任何对象的代码吗?
 
关键是面向对象的思想。随着对面向对象思想理解的加深。这种状况就会改变。
Think in C++/Java 里面有一句话:Everything is object。
可能规模比较小的程序上运用大家现在的方法比较适用。可是如果系统规模很大,那么面向对象思想就会发挥巨大的作用。
 
我写软件的时候,一般先分析一下整个系统,然后把 核心处理逻辑或数据结构之类的抽象的
东东设计成一个VCL控件,然后把控件交给别的程序员,别人把我的控件安装到delphi里面
直接调用我控件的方法、属性进行编程。 当系统核心发生变动的时候,我只要给他们最新
版本的控件即可。
不知道这是不是你说的面向对象编程?
 
面向对象和面向过程只是一种编程思想罢了,最底层的始终还是从第一条命令执行到最后
一条命令。
觉得一个过客有点想的钻牛角尖了,就像pascal不允许goto命令一样,但pascal编译出来
的exe文件不也是靠一个一个的jmp、jz等跳转命令实现pascal的for、while么。这难道就
可以说pascal就也是赞成goto命令?[:)]
 
面向对象又不是绝对的东西。
不见得软件用到了面向对象就是好软件,不用就是不好的软件。
另外说道在VCL里用到的多是继承,那么有现成的东西,不去继承也是浪费资源。
我感觉在一般的Delphi程序中,做到面向对象的最好方式就是继承,
并且尽量避免单元的交叉引用。
举个简单的例子,在一个简单的程序中,如果要引用子单元中一个EDIT的TEXT;
1、USES CHILD;
x:=CHILDFORM.EDIT.TEXT;
2、在 CHILD 中,定义一个属性
property Text:string Read GetText write SetText;

function getText:string;
{ Result:=Edit.Text;}
procedure SetText(value:string);
{ Edit.Text:=Value}
uses Child;
x:=Chile.Text;
如第二种方法,就好于第一种方法,这样子窗体就有了可以变化的灵活性。如果子窗体的界面发生变化,就不用改变主窗体的代码。
如果要传递主窗体中的参数到子窗体中。简单的在子窗体中引用主窗体无疑是后患无穷。
通过重构主窗体的构造函数,或者在子窗体中为它添加一个属性,才应该是正解。
如果软件的界面在将来需要变化,按第一种方式可有的忙了。同时团队的合作开发也才更顺利
各负责各的窗口就可以了。
如果程序中业务的流程很复杂,就应该考虑想“一个过客”所说:抽取一个独立的类出来了。
 
顶部