面向对象语言（Object Oriented language)的问题

donynam

目前有很多人都认为，面向对象语言是解决程序难题的最佳方法，可是事实上面向对象总是制造了很多不必要的麻烦，例如如何分类才能使这些那些功能与现实功能相符。

很多时候，当我使用总是为面向对象并不反映真实世界的结构而烦恼。因为往往人们在使用面向对象的时候是"蓄意"将一些自然界相关联的事物硬硬的一分为二。例如：一张椅子的三只脚拿掉，椅子还是椅子，然而类别（class）如果失去了某些功能，可能就不足以称为原来的类别。

除此之外，当我们理解类别的时候总会遇到一些如马拉松般的理解类别程序的问题。例如：当我们阅读A类别的时候，发现到A类别里有B类别，于是便跑去阅读B类别，但又发现B类别里又有C类别。。。。。直到我们都将所有的相连类别都看了一遍后，才能理解A类别到底是讲什么。这实在是浪费时间。使用面向对象语言原本就是要让程序的结构有条例，反映自然界的物件，方便阅读。然而，现在面向对象语言现在却成为了“方便阅读”的绊脚石。例如：

                        class_A
                        p = new classB
                       ----------------
                        class_B
                        q = new classC
                       ----------------
                        class_C
                        r = new classD
                       ----------------
                            ....
                       ----------------
                            ....
                       ----------------

这种阅读程序的方式，根本就是不符合人类思维的方法。例如：当我们阅读一本书的第一页时，还没有看完就跳到第二页，第二页也都还没看完就跳到第三页，等第三页看完后在跳回之前没看完的页数。

除此之外，每个写程序的人的思维、对于类别的“分类”与实现往往都是不同的。例如：有些人认为电脑必须有相伴的显示器与相关的周边设备才算是电脑，也有一些人认为，只要运算和逻辑功能的设备，就可以称为电脑。当我们谈起某样东西的时候，是不是所有人的概念都是一样的呢？在现实世界里，这是不可能的。例如：

                      人的概念的理解可能有：
                   1）人－》有手－》有脚 －》能思维
                   2）人－》身体短毛 －》直立 －》会受伤
                   3）人－》会哭 －》有感情
                               ....
                               ....

我不知道其他人是否有这样的经验，对于我来说，我不认为编写类别（class）会使以后的人能够容易的阅读代码（code）和更方的阅读。面向对象的各种美好幻想，可能只是一种乌托邦，如共产主义的经济，知易行难，与现实世界脱节。

[ 本帖最后由 donynam 于 20-11-2005 03:07 AM 编辑 ]

sson

小章鱼也不很了解 OO
不过使用类不是因为或觉得会让代码容易阅读，
而只是因为可以减轻代码和重用的方便。

要代码容易阅读，小章鱼认为不是类或什么可以帮忙的，
最重要的还是给类、变量等的命名。

donynam

原帖由 sson 于 20-11-2005 03:24 AM 发表

小章鱼也不很了解 OO
不过使用类不是因为或觉得会让代码容易阅读，
而只是因为可以减轻代 ...

不知道你有没有比较过传统的编程与OO的编程方法。其结果是使用OO编程后，程序增加了至少1倍。真是莫名其妙。

然后，又因为每个人对达到最终目的的方法都有很大的分歧，所以在阅读oo程序的时候又要与编写者做详细的沟通，以了解编写者的构思，这实在是浪费时间。为什么我们不能将时间都集中在编程那里？使用OO后反而将时间浪费在沟通方面？

至于重用（reusable）的问题，有时候我会觉得根据自己的方法重新写过，反而比理解之前的OO程序容易得多。况且，基于每个人的概念都不一样，某一个类别可能只有某部分功能合适，另一部分对于正在编写程序的人来说，可能没有用处。这时候就会遇到两难问题：使用这个类别，则会使程序增加一些多余的代码，不使用这些类别的话就必须重新写过。

ww2020

OO也不是最完美的，只是OO带来的是效率。
class分得细不一定有用，重要的是恰到好处。
有xp的人OO就可以用到接近完美。

jangancari

除此之外，当我们理解类别的时候总会遇到一些如马拉松般的理解类别程序的问题。例如：当我们阅读A类别的时候，发现到A类别里有B类别，于是便跑去阅读B 类别，但又发现B类别里又有C类别。。。。。直到我们都将所有的相连类别都看了一遍后，才能理解A类别到底是讲什么。这实在是浪费时间。使用面向对象语言原本就是要让程序的结构有条例，反映自然界的物件，方便阅读。然而，现在面向对象语言现在却成为了“方便阅读”的绊脚石

非常赞同这个观点， 我最近就是中了这样一单
那天为了fix 一个bug 读一个C++源代码， 追一个function 追到后来竟然不是出问题的那个部分(虽然还没fix)， 而是一个我之前都常读的其中一个源代码 。希望可以尽快fix 了这个bug。


structure programming  和OOP 其实是要看情况， 基本上， 小程序如patching , 简单interface uploading/downloading 用structured programming 更方便。而比较大的程序还是使用OOP 比较好。

其实OOP 只是一个概念， 可读性是根据class 的设计方式来决定， 而且， 要读OOP 源代码， 可以先看classes diagram ， 有哪些member function来拿个概念， 之后读起来就会比较容易。

莫名奇妙

很多时候，当我使用总是为面向对象并不反映真实世界的结构而烦恼。因为往往人们在使用面向对象的时候是"蓄意"将一些自然界相关联的事物硬硬的一分为二。例如：一张椅子的三只脚拿掉，椅子还是椅子，然而类别（class）如果失去了某些功能，可能就不足以称为原来的类别。

這個是觀念的問題,因為你沒有從功能面去看這件事情,
椅子拿掉三隻腳,椅子還是椅子,
這個是因為它所提供的"坐/支撐"這個功能還在的緣故,
所以沒有腳的椅子,當然也是椅子類別中的一種.
如果考慮吧椅子的椅面拿掉了,剩下三隻腳,那麼他還是椅子嗎 ?

同樣的類別也是,如果你把它的主要功能拿走了,他當然就不是原來的類別了...

p/s 物件導向其實並不必完全的反映真實世界的結構,重點是要明白物件的特性...後面會談到....

除此之外，当我们理解类别的时候总会遇到一些如马拉松般的理解类别程序的问题。例如：当我们阅读A类别的时候，发现到A类别里有B类别，于是便跑去阅读B类别，但又发现B类别里又有C类别。。。。。直到我们都将所有的相连类别都看了一遍后，才能理解A类别到底是讲什么。这实在是浪费时间。使用面向对象语言原本就是要让程序的结构有条例，反映自然界的物件，方便阅读。然而，现在面向对象语言现在却成为了“方便阅读”的绊脚石。例如：

其實我們真的有需要完全了解類別在寫什麼嗎 ? 根據物件導向的封裝原則(encapsulation),是必須把實做隱藏起來只公開操作介面的,好處是我修改程式的時候,只要沒有改變操作介面,所有引用我這個類別的人都不用改程式.

舉例來說說電視人人都會看,但是充其量也只是打開,選頻道,調聲音大小等功能,有人會去想要了解電視裡面的電子槍如何射出電子,然後如何打在銀幕上發光,如何構成畫面嗎 ? 人們最需要的,不是了解這種東西,而是我要怎樣才能看得到電視節目,所以最重要的搞不好就只是電視的"操作手冊".

所以,如果你開發一個程式,你要的只是某一個類別的"功能",所以只要注意它的操作介面就好了不是嗎 ? 找一些他的使用範例來看,通常會附在類別一起讓別人下載.

(當然如果你的目的不是開發一個程式,而是研究某個功能實作方法,那麼去看他的內部實做當然也是無可厚非的)...

这种阅读程序的方式，根本就是不符合人类思维的方法。例如：当我们阅读一本书的第一页时，还没有看完就跳到第二页，第二页也都还没看完就跳到第三页，等第三页看完后在跳回之前没看完的页数。

不,我認為這個方式是很好的,它可以讓我們先基本的了解整個架構,就好像一本書的第一頁通常是目錄,而目錄對需要快速了解這本書的讀者來說,這是ㄧ個很好的指南,當我需要第十二章的時候,我知道去那裡找第十二章.

順便談一下閱讀,
我覺得閱讀也是一樣,要徹底了解某一種知識,
就必須先把整個架構觀念建立起來,
之後再針對每個架構的空白地方填入第一章,第二章所讀到的細部知識.
當然從第一頁跳到第二頁看起來沒有連慣性,
但是如果我們把他往上提一個層次,
從第一章跳到第二章這種跳躍法,正符合了知識架構中的填入

除此之外，每个写程序的人的思维、对于类别的“分类”与实现往往都是不同的。例如：有些人认为电脑必须有相伴的显示器与相关的周边设备才算是电脑，也有一些人认为，只要运算和逻辑功能的设备，就可以称为电脑。当我们谈起某样东西的时候，是不是所有人的概念都是一样的呢？在现实世界里，这是不可能的。例如：
   [quote]
                      人的概念的理解可能有：
                   1）人－》有手－》有脚 －》能思维
                   2）人－》身体短毛 －》直立 －》会受伤
                   3）人－》会哭 －》有感情
                               ....
                               ....
   

[/quote]

你所說的這個問題牽涉到兩種情形.

1. 名稱的不同
比如電腦有人把它叫做電腦,也有人叫做計算機,所以這個是命名的問題,這個問題比較小,只是讓人覺得不好理解吧了.

2. 類別構成的問題
一個物件,比如說飛機
不同人看的時候他的觀點是不一樣的

例如

乘客    飛機 ->> 寬敞嗎   ->> 座位舒服嗎 ->> 設備好嗎
科學家  飛機 ->> 飛的原理 ->> 飛行數據   ->> 與地心引力的變化
機場    飛機 ->> 飛機型號 ->> 燃料消耗度 ->> 性能

這個是因為他們出於本身需求的考量,也就是他們希望飛機這個類別所提供的"功能"是什麼.

基本上,設計類別的時候,
不要以類別作導向,而儘量以功能做導向,

這樣一來,雖然每個人觀念中的飛機都不一樣,

但是至少乘客和乘客談的飛機都是差不多的東西,也許只是名稱不同和一些小差異

不會出現乘客和科學家的對話,因為雖然是飛機,但他們所考慮的東西根本不在一個平面上.

我不知道其他人是否有这样的经验，对于我来说，我不认为编写类别（class）会使以后的人能够容易的阅读代码（code）和更方的阅读。面向对象的各种美好幻想，可能只是一种乌托邦，如共产主义的经济，知易行难，与现实世界脱节

我認為類別的確沒有讓人更容易閱讀代碼,因為它只是類別
但是物件導向就能,因為裡面不只有類別,還包含了許多設計的守則.
如果只是單純的把程式設計成類別.那麼的確到不如不用....

而且我認為,代碼不是拿來閱讀的,我們要讀的東西,其實是使用說明書...

[ 本帖最后由 莫名奇妙 于 20-11-2005 06:59 PM 编辑 ]

莫名奇妙

原帖由 donynam 于 20-11-2005 10:51 AM 发表

不知道你有没有比较过传统的编程与OO的编程方法。其结果是使用OO编程后，程序增加了至少1倍。真是莫名其妙。

然后，又因为每个人对达到最终目的的方法都有很大的分歧，所以在阅读oo程序的时候又要与编写者做详细的沟通，以了解编写者的构思，这实在是浪费时间。为什么我们不能将时间都集中在编程那里？使用OO后反而将时间浪费在沟通方面？

既然每個人的目的都一樣,那麼用什麼方法達成有差別嗎 ?
因為從基本的地方看,我只是要用這個class的某些功能,
只要它提供的功能已經滿足了你的需求,那麼為什麼需要去 trace 它的程式碼 ?
只要看他的說明文件就好了不是 ?
如果說他的效率不好,那麼就整個換掉,用一個效率好的補上,對你的程式碼還是沒有太大的影響

至于重用（reusable）的问题，有时候我会觉得根据自己的方法重新写过，反而比理解之前的OO程序容易得多。

而你所說的重用問題,用自己的方法重新寫過,應該就不叫做重用了吧,如果我寫10個類似的程式,我都要把同樣的功能重寫10次 ? 或者 copy paste 10 次嗎 ?

况且，基于每个人的概念都不一样，某一个类别可能只有某部分功能合适，另一部分对于正在编写程序的人来说，可能没有用处。这时候就会遇到两难问题：使用这个类别，则会使程序增加一些多余的代码，不使用这些类别的话就必须重新写过。

如果把話反過來說的話,沒有用物件導向,那麼就連選擇的權利都沒有不是 ?
因為一律要重新寫過....


純討論

莫名奇妙

原帖由 jangancari 于 20-11-2005 02:30 PM 发表


非常赞同这个观点， 我最近就是中了这样一单
那天为了fix 一个bug 读一个C++源代码， 追一个function 追到后来竟然不是出问题的那个部分(虽然还没fix)， 而是一个我之前都常读的其中一个源代码 。希望 ...

結果修好了嗎 ??

structure programming  和OOP 其实是要看情况， 基本上， 小程序如patching , 简单interface uploading/downloading 用structured programming 更方便。而比较大的程序还是使用OOP 比较好。

同意,沒有必要全部都用 OO , 因為OO的好處是在整合方便,重用簡單,而效率則不是他那麼注重的考量

其实OOP 只是一个概念， 可读性是根据class 的设计方式来决定， 而且， 要读OOP 源代码， 可以先看classes diagram ， 有哪些member function来拿个概念， 之后读起来就会比较容易。

沒錯沒錯,所以才會用 UML 的出現.....
程式碼是最後沒辦法的時候才去讀的......

goatstudio

看到这帖, 想起了以前我第一次学习物件导向的痛苦经验. 第一次接触物件导向写法还是在学院的时候, 用的语言就是当红的 Java 了. 那时候我也有类似楼主的千百个疑问. 最大的疑问就是, 我懂的怎么写, 我也懂的概念, 我更懂得如何去应付物件导向考卷问题, 但是要如何真实应用物件导向的概念?

后来接触的开发工作越来越多… 逐渐了解物件导向的好处. 基本上, 莫名其妙兄已经解说了大部分的疑问. 我想在这里分享在工作上运用物件导向的经历, 也许实际例子会比较容易明白吧.

要了解这概念花了我好几年的时间, 大部分是在一知半解中摸索得来的. 但是可以肯定的是, 物件导向的出现, 是为了解决越来越复杂的程序, 趋向团体开发的软件, 还有模组重复应用.

面向对象的各种美好幻想，可能只是一种乌托邦，如共产主义的经济，知易行难，与现实世界脱节。

现实中, 你所接触的, 已经是物件导向所设计的软件. 举个简单的物件导向例子来说, 我的 Windows XP 里的桌面, 有至少三个小 icons, 它们是我的电脑, 资源回收, 还有我的电邮软件, Thunderbird. 它们的种类全是 icon, 所以才得以放在 desktop 上. 但是, 当在我们更深一层探讨这三个简单的小 icons 时, 会发现这三个 icons 其实有同一个属性, 却是不同的种类. 我的电脑在滑鼠右键后, 会出现关于当前电脑的各种咨询, 资源回收会出现之前所删除的文件, 而 Thunderbird 就纯粹只是一个普通的 shortcut. 这就是物件导向里的继承( inheritance) 了. 这三个小 icons 都继承了 icon 的 class, 却又是不同的种类.

以上的例子是最实际的案例, 如果要用 structured language 来写, 恐怕难以达到这目的. 在 GUI 还没大肆流行前, 大家大多用的是指令界面 (Command Line Interface), 例如 Unix 或 DOS, 这类系统简单的只是接受字串 (string) 来辨别接下来应该做什么, 基本上一点也没有今天的 GUI 那么复杂.

这种阅读程序的方式，根本就是不符合人类思维的方法。例如：当我们阅读一本书的第一页时，还没有看完就跳到第二页，第二页也都还没看完就跳到第三页，等第三页看完后在跳回之前没看完的页数。

其实呢, 我们不应该阅读程序的, 我们应该阅读的是开发手册, 里面有详细的指令和各种 diagram 来帮助我们了解程序. 这就是为什么全部的开发员应该要有写开发手册的能力, 学院也相当注重开发手册的编写. 另外, 现今的软件来说, 也根本没有照着人类的思维. 一个人打开 windows 后, 你能预测他会做什么吗? 他会去打开 words? 还是去打开游戏? 基本上, 这是互动 (interactive) 的时代, 良好的物件导向设计能限制只有必要的物件存放在记忆里, 不必要的全部撤销, 这就是 Java 在当年红极一时的原因, 因为 Java 有内建自动撤销多余的物件的功能.

至于重用（reusable）的问题，有时候我会觉得根据自己的方法重新写过，反而比理解之前的OO程序容易得多。况且，基于每个人的概念都不一样，某一个类别可能只有某部分功能合适，另一部分对于正在编写程序的人来说，可能没有用处。这时候就会遇到两难问题：使用这个类别，则会使程序增加一些多余的代码，不使用这些类别的话就必须重新写过。

关于这点, 我再说明一个最实际的例子, 也就是我在我的工作上所应用的. 话说一年多前, 我正在开发一个类似 claiming 系统的软件. 我选择了 C# .Net (.Net/Java 和这主题无关). 我是开发组长, 我的小组有 SAP 人员, 还有好几个合约开发员, 更有一个专门负责流程的顾问. 几乎每个人都有自己的任务.

这是一个相当复杂的系统, 考虑到会有五个国家, 超过20 间子公司同时一起用这系统, 每间子公司更可能有少许不同的 policy, 可能会造成软件也许不适合某些公司用.为了这点, 软件设计就变得极为重要. 我们在设计软件上所花的时间远远超出实际开发 (deployment) 的时间. 还好最后还是顺利完成了. 接下来的一年, 就是在每一间公司的巡回演示, 让子公司的员工使用, 这段时间花了足足一年 (分段演示, phases).

众所周知, 要在软件开发之前收集 100% 的用户需求是不可能的, 充其量只能勉强达到 70% (这就是为什么会有软件 patch/service pack 的原因). 结果在巡回演示的时候, 我们在其中一个国家就遇到了困难.

开发员 A 所设计的 “员工” (Employee) 物件只能满足大部分公司, 小部分公司有更多资料要装载! 我们这时候不能去修改这 “员工” 的物件, 因为这物件已经被大量应用在软件里, 修改的话也许会造成重大的错误, 甚至本来完美无缺的流程, 也许会出现不可以遇见的错误 (flaw). 我们当时一致的决定是, 建立一个新的 “员工” 物件.

为了让这新的 “员工” 物件能良好的在当前的软件模组里应用, 也能应用在新的专门模组里, 物件导向里的承接 (inheritance) 还有界面 (interface) 就派上用场. 这就是所谓的重用 (reusable), 用新瓶装载旧酒, 解决了当前的问题, 也能完整无缺的和以前的模组配合. 想想看… 如果当时要开发一个新的软件来解决这小部分公司的问题, 所花的时间是多么的大, 通过物件导向的方便, 只是在软件的一处修改了一些, 完全没碰到主核心.

然后，又因为每个人对达到最终目的的方法都有很大的分歧，所以在阅读oo程序的时候又要与编写者做详细的沟通，以了解编写者的构思，这实在是浪费时间。为什么我们不能将时间都集中在编程那里？使用OO后反而将时间浪费在沟通方面？

这其实是物件导向的目的, 减少组员的分歧. 基本上, 物件导向在我眼里看来, 能更好的协调组员中的合作和互动. 例如说, 开发这模组的员工不需要去深入了解别的模组, 开发用户界面的员工更不需要去深入资料库的设计. 当然, 在这些的大前提是, 大伙的观点要达到一致, 领导成员的协调也很重要.

举个例子来说, .Net 可以很好的把界面和核心里的资料/资料库分开. 我们在软件设计里就大量运用了 DataGrid 配合 DataView, 而负责运用这两个物件的组员基本上对资料库设计完全置之不理,这组员只是负责把 物件的 variables 填满 DataView, 再由 DataGrid 显示出来. 因为物件的真实资料设计已经由另一人负责, 没必要的 variables 也已经被隐藏 (private/protected) 以免造成混乱.

不知道你有没有比较过传统的编程与OO的编程方法。其结果是使用OO编程后，程序增加了至少1倍。真是莫名其妙。

这倒是真的. 当然, 简单的程序, 糟糕的设计会让物件导向不但无用武之地, 还会因此破坏本来的流程和速度. 但是, 在现今的电脑普及下, 用户的需求越来越高, 也越来越挑剔… 软件设计也变得越来越复杂, 这就是物件导向在今天大行期道的原因.

也许这样想, 当初我还在津津有味的玩着 space invader, pong, 射击 king kong, 几年后就因 Sonic Hedgehog 而惊叹原来游戏可以这样… 然后再几年后, 就是类似 Diablo 这些游戏在玩我而不是我玩它… 象这类的游戏, 有多支线结局, 又有无可预测的敌人, 还有可以和大伙一起玩的功能… 传统的编程怎么可能应付得来呢?

以上纯粹是个人的分享, 没有绝对的对或错.

exiang

感觉上，OOP并不是常常都合用的。

但写游戏，尤其是复杂的，就像STRATEGY GAME等，都有需要使用ＯＯＰ，否则我也不感想象要如何去写。

jangancari

很精彩的一个讨论！ 莫名奇妙, goatstudio 说得一针见血， 道出了OOP的利与弊。

上次也有谈过， fxam 还是白日梦版主也提到了一个反OOP的网站， 说明OOP不适合在数据库的资料控制上。
他们提出TOP， Table oriented programming （如果没有记错）， 配合structured 和OOP的优点在数据库软件上应用。以我用过/读过几种电脑语言开发的数据库程序的经验， 我觉得他们说的有点道理， 我个人RPG/400 的数据库程序编程就好过OOP（在于数据功能方面， GUI 方面就输倒倒）。

当然， RPG/400 本来就是来设计数据库软件的， 这方面当然有点优势， 可是也说明了OOP 在数据库程序上有进步的空间， 就像他们提出的TOP.

原帖由 莫名奇妙 于 20-11-2005 03:45 PM 发表

結果修好了嗎 ??

还没有 ， 也因为是主程序基本class 最近有大更改， 编译不成功， 昨天才成功编译。

同意,沒有必要全部都用 OO , 因為OO的好處是在整合方便,重用簡單,而效率則不是他那麼注重的考量

对， 程序大对应用软件来说不是最大的关键， 源代码的易管理性， 程序编程工作的分配性更加重要。
我相信好的OOP设计， 效果出来不会差到太远。

沒錯沒錯,所以才會用 UML 的出現.....
程式碼是最後沒辦法的時候才去讀 ...

正是如此， 我fix 那个bugs 就是因为有OOP 我才找到起点开始trace ， 如果是structure programming ， 我觉得很难。


还有， debugging 技术也是很重要， 一些外国的编程员的debugging 技术非常好， 读core dump ， set break point 的技术， 利用msgbox 来抓程序的flow ， 我个人的OOP技术就是不好， 只懂概念， 不懂设计。
不过有概念也非常方便阅读源代码了。


大家讨论到OOP ， 不如也谈谈一个非常有关系的题目event driven 。 当软件开发发展到让使用者有选择任何input 的时候， event driven programming也成了一定的编程方式。
好的OOP设计配合清楚地event driven 的 function 名称，应该有减少源代码难读的程度。

donynam

原帖由 莫名奇妙 于 20-11-2005 03:20 PM 发表
這個是觀念的問題,因為你沒有從功能面去看這件事情,
椅子拿掉三隻腳,椅子還是椅子,
這個是因為它所提供的"坐/支撐"這個功能還在的緣故,
所以沒有腳的椅子,當然也是椅子類別中的一種.
如果考慮吧椅子的椅面拿掉了,剩下三隻腳,那麼他還是椅子嗎 ?

同樣的類別也是,如果你把它的主要功能拿走了,他當然就不是原來的類別了...

p/s 物件導向其實並不必完全的反映真實世界的結構,重點是要明白物件的特性...後面會談到....

假设要从功能上去考虑OO的话，不如直接使用传统的函数（Function），那将会更加快速。况且OO所考虑的重点是那些物件（object）到底能不能达到目的。通过什么方法或功能达到不是OO专注的。这也是为什么有人提出黑箱（Black Box）的概念：不需要理解类别内部（class），只要知道输入什么，得出什么结果就行了。

其實我們真的有需要完全了解類別在寫什麼嗎 ? 根據物件導向的封裝原則(encapsulation),是必須把實做隱藏起來只公開操作介面的,好處是我修改程式的時候,只要沒有改變操作介面,所有引用我這個類別的人都不用改程式.

舉例來說說電視人人都會看,但是充其量也只是打開,選頻道,調聲音大小等功能,有人會去想要了解電視裡面的電子槍如何射出電子,然後如何打在銀幕上發光,如何構成畫面嗎 ? 人們最需要的,不是了解這種東西,而是我要怎樣才能看得到電視節目,所以最重要的搞不好就只是電視的"操作手冊".

其实是不需要知道类是如何写。不过先决条件是必须要有很好的辅助文件或者操作手册。如果总是认为全部程序都有很好的辅助文件或者操作手册的话，可能太过乐观了。尤其是在网络上的一些程序，很多都是没有很好的辅助文件或者操作手册，这时候，我们除了怪编写这些程序的人外，为何没有想到OO是导致程序很难阅读的原因之一？

不,我認為這個方式是很好的,它可以讓我們先基本的了解整個架構,就好像一本書的第一頁通常是目錄,而目錄對需要快速了解這本書的讀者來說,這是ㄧ個很好的指南,當我需要第十二章的時候,我知道去那裡找第十二章.

这种说法太过牵强了。我不否认有人可以做到跳跃似的阅读书本，但是根据人一般的习惯，人们习惯一页接一页的看下去，直到某个阶段。

這個是因為他們出於本身需求的考量,也就是他們希望飛機這個類別所提供的"功能"是什麼.

基本上,設計類別的時候,
不要以類別作導向,而儘量以功能做導向,

我还是不认为类别应该以功能作为导向，类别应该以它能完成什么为导向也就是目的。例如： 制造一辆汽车，我根本就不必理会它内部有什么功能。我只要知道这辆汽车是否能载人就可以了。

既然每個人的目的都一樣,那麼用什麼方法達成有差別嗎 ?
因為從基本的地方看,我只是要用這個class的某些功能,
只要它提供的功能已經滿足了你的需求,那麼為什麼需要去 trace 它的程式碼 ?
只要看他的說明文件就好了不是 ?
如果說他的效率不好,那麼就整個換掉,用一個效率好的補上,對你的程式碼還是沒有太大的影響

如果个人演出（One man show）的确是没有差别。不过，如果是团队的话，没有经过好好的沟通，可能会出现概念上的误解。

而你所說的重用問題,用自己的方法重新寫過,應該就不叫做重用了吧,如果我寫10個類似的程式,我都要把同樣的功能重寫10次 ? 或者 copy paste 10 次嗎 ?

重用的概念是这些写好的类别可以被后续者拿来使用，不必重新写过。然而，就因为大家都同意OO根本就没有使程序变得容易阅读，所以与其花时间在阅读这些类别，不如重写。

如果把話反過來說的話,沒有用物件導向,那麼就連選擇的權利都沒有不是 ?
因為一律要重新寫過....

概念不同的事物无法比较。沒有用物件導向，只好用函数（Function）去解决问题了。函数也是可以重用（reuse）的。

flashang

我在开始学 OO 时，觉得无端端的把东西分成那么多层干吗？很容易的东西变得很乱

某一天我做了一个 OO 的蛇（蛇吞蛋里的蛇，每一个 node 会用 method 来跟着前面走）后，发现适当的 OO 的确比我以前的做法好

后来做了一些 OO 的实验，发现其实 OO 也是建立在 procedure 之下（method 就好像 function），
只是管理方法不同。。。就好像 windows 里的 control, 大都从一个比较简单的 object 而近化而来。

其实 OO 提供了不同管理 code 的方法。
如果你写 procedure 不好，使用 OO 也会一大堆 bug

说穿了就一句话: 用适合的 工具 / 方法 做适合的事

donynam

原帖由 goatstudio 于 20-11-2005 08:22 PM 发表
看到这帖, 想起了以前我第一次学习物件导向的痛苦经验. 第一次接触物件导向写法还是在学院的时候, 用的语言就是当红的 Java 了. 那时候我也有类似楼主的千百个疑问. 最大的疑问就是, 我懂的怎么写, 我也懂的概念, ...

无可否认在一些特殊的情况下，OO有它本身的好处，然而考虑到一般的情况，OO可以完成的，非OO的也必定能够完成。如果要求效率高的及时（real time）系统, 解决OO低效率的方法，除了提高硬件外别无他法。如果要求的效率不高，OO不失一个解决问题办法，但不是唯一的办法。

根据以往的记录，可以发现到目前电脑cpu的速度，在提升方面似乎已经慢了下来，CPU反而往多线程（Multi Thred）的方向和提高流量方面发展。而OO语言如果还是一味以提升硬件速度为解决效率的问题，恐怕已经到了极限。此外，OO在多线程方面，也比较难享受到多线程的好处，因为在类别里面，很难将资料与指令（command），完全分开独立处理。

另外，我要说的是OO本来的用意就是要让编写的程序，反映世界真实的情况。如果我们要做一些部分反映真实，部分自定的话，可能会违反OO原本的用意。

goatstudio

假设要从功能上去考虑OO的话，不如直接使用传统的函数（Function），那将会更加快速。况且OO所考虑的重点是那些物件（object）到底能不能达到目的。通过什么方法或功能达到不是OO专注的。这也是为什么有人提出黑箱（Black Box）的概念：不需要理解类别内部（class），只要知道输入什么，得出什么结果就行了。

概念不同的事物无法比较。沒有用物件導向，只好用函数（Function）去解决问题了。函数也是可以重用（reuse）的。

物件导向的出现, 就是要解决这种传统的函数所带来的问题. 虽说很方便, 举个最佳的例子就是 VBScript/Javascript/PHP. 但是这类函数的功能却是极有限, 而且好多时候也无法达到我们的特定要求. 透过物件导向里的承接 (inheritance) 和多型性 (polymorphism) 却可以直接修改某个函数来达到不同的效果, 这是只有物件导向才能达到的.

注: Javascript 本身可以达到多型性. 但如果你了解到 Javascript 的主要结构的话, 它基本上是由 elements 组合, 再加上内涵 (static methods). 这算是简化了的物件导向, 类似 VB6.

也许你会问, 这有什么用呀… 我得告诉你一个实际的例子. 在真实的商业环境中, 各种需求千变万化, 很多时候会有多方的需求, 不同种类的资料集聚. 以下是 C£ 的代码:

public Employee CreateNewEmployee () {
   return CreateNewEmployee (System.Guid.NewGuid().ToString());
}

public Employee CreateNewEmployee (string id) {
   // anything
}

以上的代码说明了, 要取得一个 Employee 的物件可以透过两种不同的方法, 这是为了适应各种商业环境的需求而设计的. 如果放不同的名字的话, 可能会造成误导, 其他人员也会莫名其妙. 别忘了… 现在的编程不是个人的… 是团体. 即使现在是个人, 我们还得需要有远见呢.


其实是不需要知道类是如何写。不过先决条件是必须要有很好的辅助文件或者操作手册。如果总是认为全部程序都有很好的辅助文件或者操作手册的话，可能太过乐观了。尤其是在网络上的一些程序，很多都是没有很好的辅助文件或者操作手册，这时候，我们除了怪编写这些程序的人外，为何没有想到OO是导致程序很难阅读的原因之一？

这不是乐观呢… 这是一个首要条件, 或必须的条件. 试想, 即使是一个传统的方式没有很好的文件… 那时候你也会叫苦连天, 还会更痛苦… 因为一大堆集聚在一起的涵数 (在物件导向, 不必要的函数都被隐藏), 有些好家伙还去运用到 Goto, 形形色色的 header 文件… 这就是为什么当我听到现在的好些学生高手沾沾自喜说自己从不做开发手册而感到担忧. 现在你可明白为什么有些只可当编程员为什么有些不太懂编程却可越爬越高吧.

这种说法太过牵强了。我不否认有人可以做到跳跃似的阅读书本，但是根据人一般的习惯，人们习惯一页接一页的看下去，直到某个阶段。

现在的电脑是互动的, 软件也是如此. 一个 RPG 之所以好玩因为它能根据用户的反应来决定下一步. 网上游戏更好玩是因为对手是人, 人比电脑更互动.
当在一个完全互动的环境下… 运用传统的方法你将会写的比物件导向来得长, 查找臭虫也会更难. 我永远也忘不了我在学院打印出四百张的 C 函数要找出问题在那里.现在的物件导向下, 我可以根据 event 找出是那一个物件出现问题从而解决它. 要记得, 是其中之一的物件, compile 那物件后就可以继续运行其它物件了.

如果个人演出（One man show）的确是没有差别。不过，如果是团队的话，没有经过好好的沟通，可能会出现概念上的误解。

重用的概念是这些写好的类别可以被后续者拿来使用，不必重新写过。然而，就因为大家都同意OO根本就没有使程序变得容易阅读，所以与其花时间在阅读这些类别，不如重写。

这些我在上一个回复已经回答了. 重写是必须的. 但很多时候你无法完全重写. 小型软件可以, 但大型项目不允许你那么做. 再说, 大型项目里, 每个人有自己的任务, 如果一个人改一个资料库的设计就要改界面 (例如 ASP/PHP), 那时候问题就大了.

注: 在 .Net DataView 下, 这是一个虚拟 table, 可以直接把物件的资料输入这 DataView, 从而达到物件完整的保安性和封装. 负责界面的人员只会看到你想给他看的结果, 而不是整个资料库, 甚至一个 table 的设计.

无可否认在一些特殊的情况下，OO有它本身的好处，然而考虑到一般的情况，OO可以完成的，非OO的也必定能够完成。如果要求效率高的及时（real time）系统, 解决OO低效率的方法，除了提高硬件外别无他法。如果要求的效率不高，OO不失一个解决问题办法，但不是唯一的办法。

一般的情况是指怎么样的情况呢? 象我之前所回复你的, 有好些任务勉强可以用 ASP/PHP 完成, 但是善后处理 (maintenance), 修改, 还有加进各种功能将会是一个恶梦. 这样想好了, 当你车子坏了, 工人就会修理坏的那部分会撤换, 而不是把整辆车拆了再组合给你. 再说, Windows 就是一个活生生物件导向的例子.

根据以往的记录，可以发现到目前电脑cpu的速度，在提升方面似乎已经慢了下来，CPU反而往多线程（Multi Thred）的方向和提高流量方面发展。而OO语言如果还是一味以提升硬件速度为解决效率的问题，恐怕已经到了极限。此外，OO在多线程方面，也比较难享受到多线程的好处，因为在类别里面，很难将资料与指令（command），完全分开独立处理。

这完全不合理呢. 我还记得 Java 最令我兴奋的功能是 multi threaded. 你可以设计同一时间运行多个运算. 如果你要在 C 里那样做你需要 spawn, 那是痛苦的经历. 物件导向的出现也是为了解决多线程, 你在 windows 里不是可以一面听歌一面上网吗? 那是因为每个物件在运行自己的功能, 运用完后就撤销, 没有必要的代码也就不会留在记忆体里. 想当初, 要达到这效果需要用 spawn 和 一大堆古怪的方法, 这是我最怕的地方.

另外，我要说的是OO本来的用意就是要让编写的程序，反映世界真实的情况。如果我们要做一些部分反映真实，部分自定的话，可能会违反OO原本的用意。

这是真的. 一个坏的设计会导致物件导向变得更复杂, 甚至更慢. 不过呢, 要了解的是, 物件导向的出现, 除了解决当今复杂的需求, 还有趋向团体开发, 最大的原因就是为了从用户着手去解决问题. 你在学院肯定念过 HCI (Human Computer Interface), 那么肯定了解 metaphor modeling. 一个编程员只有一个目的, 那就是 problem solving (IT 的第一课). 软件不应该跟着编程员的意愿, 而是用户的烦恼和需求. Metaphor Modeling 就是为了让用户使用软件的时候更贴近真实环境. 例如说把不要的文件丢进垃圾桶.

物件导向的出现就是要把设计焦点拉回流程上, 这就是为什么一个完整的 UML 有 Case Diagram, Class Diagram, Sequencer Diagram… 除非你的软件小型, 或不考虑升级, 否则在真实环境中, 你的软件必须贴近用户的需求, 用户所要求的流程, 这样才会有人使用. 很多时候很多编程员远抱怨用户问题多多… 但是如果那软件是跟着编程员的想法来设计那软件肯定完蛋.

分享一下: 在我开发之前的一个软件前, 由于对象超过 1500 人, 从初级到经理级都有, 所以在收集需求 (requirement gathering) 之前, 就开始做了调查, 分发调查卷… 看看用户倒底想要什么… 然后积聚做一个结论, 然后就是 class modeling. 前后花了好几个月, 才开始做 coding, coding 只花了两个月.

注: 无可否认很多用户都很笨. 但就是因为笨所以我们无法要求他们和我们的思维一样. 我们看来愚不可及他们看来却是理所当然.

goatstudio

原帖由 jangancari 于 20-11-2005 11:24 PM 发表
还有， debugging 技术也是很重要， 一些外国的编程员的debugging 技术非常好， 读core dump ， set break point 的技术， 利用msgbox 来抓程序的flow ， 我个人的OOP技术就是不好， 只懂概念， 不懂设计。
不过有概念也非常方便阅读源代码了。

这里不得不提提 Visual Studio .Net. 早在 VS 6 的时代, 微软已经提供了相当优越的 debugging tools, 可以一层一层深入进行 trace.

在 VS.Net 的时代里, 我设计软件的时候会把核心和界面分成两个 projects, 然后在界面的 project 里加入核心的 DLL. 结果在做 debugging 的时候, 只要注明核心的 code 在那里, VS.NET 竟然可以从一个 project 进入另一个 project 进行 debug! 这大大出乎我意料之外. 不管是 web project 还是 application, VS.NET 的支援都十分杰出.

当然... 这也充分说明了 .Net 实在很容易被 decompile...

Java 杰出的 debugger 我只能想到 Borland JBuilder.

[ 本帖最后由 goatstudio 于 21-11-2005 09:23 AM 编辑 ]

donynam

这些我在上一个回复已经回答了. 重写是必须的. 但很多时候你无法完全重写. 小型软件可以, 但大型项目不允许你那么做. 再说, 大型项目里, 每个人有自己的任务, 如果一个人改一个资料库的设计就要改界面 (例如 ASP/PHP), 那时候问题就大了.

的确，如果都需要重写的那就违反了OO的重用(reuse)概念了。

这完全不合理呢. 我还记得 Java 最令我兴奋的功能是 multi threaded. 你可以设计同一时间运行多个运算. 如果你要在 C 里那样做你需要 spawn, 那是痛苦的经历. 物件导向的出现也是为了解决多线程, 你在 windows 里不是可以一面听歌一面上网吗? 那是因为每个物件在运行自己的功能, 运用完后就撤销, 没有必要的代码也就不会留在记忆体里. 想当初, 要达到这效果需要用 spawn 和 一大堆古怪的方法, 这是我最怕的地方.

Java 的多线程(multi threaded)是建立在虚拟机(Virtual Machine)上，它并不是正真的多线程。Windows里的多线程不是通过虚拟机完成的。Java 的多线程在系统那里只不过是虚拟机进程(Task)罢了。有时候，参考书并没有说得太详细，所以才会产生一些美丽的，有幻想的误会。

[ 本帖最后由 donynam 于 21-11-2005 06:22 PM 编辑 ]

chu10

如果没有flow chat 或 block diagram 的话。
别人的程式码本来就很难读。

AMADEUS82

OOP是目前被应用最广的设计思想，目前为止它能解决很多的设计问题。有很多的概念都是基于OOP而衍生出来的。
比如开源界有个很红的框架叫做Spring的，就是使用Inversion of Control的概念，这是由关系到OOP的。

现在很多的开源方案都有一种普遍的概念，就是允许当日后开发时，你建立的一个物件，可以插入到原本的母体去而丝毫不影响母体。这也是基于物件导向设计思想的。

我们不能排除有一天会有更好的设计思想出来。呵呵。

莫名奇妙

其實說了這麼多,物件導向只是入門,真正的菁華在 Design Pattern ,  如果你沒有對物件導向很熟悉,是不能體會她的精妙之處的, Design Pattern 實在太神奇了.... 哈哈.....第一次有看武林秘笈的感覺....