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

easemind · 2002-09-06

虽然面向对象编程离我们很近。但是很少能亲身用到。
比如form button, 控件。都是面向对象的。
但是在我们的程序中体现了多少
我们更多用的是继承。比如 delphi的form ,看一看代码。是面向对象的。
问题是这些代码不是我们生成的。我们更多的是在过程里填写代码。
所以我的理解是是我们虽然用的是面向对象工具，但骨子里还是面向过程的。
不知道大家什么想法。

easemind · 2002-09-06

另外一点，更多是在表现（界面是一个例子）用到面向对象。而且问题或者软件设计的本身
用的不是oop. 如果谁使用绝对的面向对象能不能提供一个具体实例？

easemind · 2002-09-08

不知道为什么没有人回应？我觉得这个问题很尖锐。我也很困惑。
我看了很多别人的程序，还有自己写的程序。还没有见过真正体现面向对象的思想在应用。
这个问题还不严重？不值得思考？？？？如果去掉界面和很多表面的东西。
纯粹的个人编程思想里面有谁在用面向对象编程。谢谢。请大家考虑一下
工具是面向对象的不代表你做的事情和分析方法是面向对象的。
我可能说的不是很清楚，我认为大概意思大家也明白。

kingde · 2002-09-16

其实只要你看过有关体系结构方面的书，你就会认识到对象无所不在，计算机的世界其实和我们
生活的世界一样，由对象组成。每个对象之间彼此联系，共同完成某项任务。对象以接口的
方式供外界访问，对象可以以ocx，dll等等方式存在，其实系统的任何东西你都可以看作对象
对象一多就会乱，就要有东西来统一它们，这就是COM。windows2000等系统其实不是用某种
面向对象的语言编写的，微软下一代的系统则会是真正的面向对象。个人认为面向对象指不过
是一种思维方式，也许人们认为编程的思维方式应该和认识世界的方式一样。
比如form button等等控件无处不体现了面向对象的观点，要创建一个form或button，好，可以
从COM中创建它们的实例。建议你看一下COM本质论。

zhuzhenyu · 2002-09-21

多学点java或c++的非delphi程序语言，对你本身也是一种促进，对编程思想是一种提升，
不能说做delphi 就必须学delphi，时间长了，发现并非语言本身的问题。在于编程思想的问题。

hnyangbin · 2002-09-21

同意zhuzhenyu, 的看法。
╭══╮
╭╯ΘΘ║
╰⊙═⊙╯。oо○看啦~~~~~~，我给你送月饼来了！

fssky · 2002-11-20

>>我看了很多别人的程序，还有自己写的程序。还没有见过真正体现面向对象的思想在应用。
>> 这个问题还不严重？不值得思考？？？？如果去掉界面和很多表面的东西。
>>纯粹的个人编程思想里面有谁在用面向对象编程
VCL就是一个采用面向对象思想的一个很好的体系架构,你有没有看看,

plzw · 2002-11-30

同意楼上的。

it_boy69 · 2003-01-11

我觉得easemind的说法有点偏见
你在过程中填写代码
但是你不是在写以前那种纯代码啊
你是在写某一对象的某一事件的代码啊
你能在DELPHI中写出不属任何对象的代码吗?

fsb2001 · 2003-03-13

关键是面向对象的思想。随着对面向对象思想理解的加深。这种状况就会改变。
Think in C++/Java 里面有一句话：Everything is object。
可能规模比较小的程序上运用大家现在的方法比较适用。可是如果系统规模很大，那么面向对象思想就会发挥巨大的作用。

一个过客 · 2003-03-14

我写软件的时候，一般先分析一下整个系统，然后把核心处理逻辑或数据结构之类的抽象的
东东设计成一个VCL控件，然后把控件交给别的程序员，别人把我的控件安装到delphi里面
直接调用我控件的方法、属性进行编程。当系统核心发生变动的时候，我只要给他们最新
版本的控件即可。
不知道这是不是你说的面向对象编程？

fshell · 2003-03-14

面向对象和面向过程只是一种编程思想罢了，最底层的始终还是从第一条命令执行到最后
一条命令。
觉得一个过客有点想的钻牛角尖了，就像pascal不允许goto命令一样，但pascal编译出来
的exe文件不也是靠一个一个的jmp、jz等跳转命令实现pascal的for、while么。这难道就
可以说pascal就也是赞成goto命令？[

]

wk_knife · 2003-03-14

面向对象又不是绝对的东西。
不见得软件用到了面向对象就是好软件，不用就是不好的软件。
另外说道在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;
如第二种方法，就好于第一种方法，这样子窗体就有了可以变化的灵活性。如果子窗体的界面发生变化，就不用改变主窗体的代码。
如果要传递主窗体中的参数到子窗体中。简单的在子窗体中引用主窗体无疑是后患无穷。
通过重构主窗体的构造函数，或者在子窗体中为它添加一个属性，才应该是正解。
如果软件的界面在将来需要变化，按第一种方式可有的忙了。同时团队的合作开发也才更顺利
各负责各的窗口就可以了。
如果程序中业务的流程很复杂，就应该考虑想“一个过客”所说：抽取一个独立的类出来了。

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

easemind

Unregistered / Unconfirmed

easemind

Unregistered / Unconfirmed

easemind

Unregistered / Unconfirmed

kingde

Unregistered / Unconfirmed

zhuzhenyu

Unregistered / Unconfirmed

hnyangbin

Unregistered / Unconfirmed

fssky

Unregistered / Unconfirmed

plzw

Unregistered / Unconfirmed

it_boy69

Unregistered / Unconfirmed

fsb2001

Unregistered / Unconfirmed

一个过客

Unregistered / Unconfirmed

fshell

Unregistered / Unconfirmed

wk_knife

Unregistered / Unconfirmed

Similar threads