今天我在這里說OO表達(dá)能力不足， 估計沒人會信， 但是這真有可能是問題的核心所在， 如果是這樣， 那么用歪了也罷學(xué)習(xí)困難也罷， 錯不在使用者和學(xué)習(xí)者， 而在于OO自身（這種質(zhì)疑也不是一天兩天了，不過大多數(shù)言論都是外延法，強調(diào)主觀因素， 所以不具說服力）。

　　這篇文章中的思路首先要歸功于songcan兄弟刨根問底的精神和腦袋兄與我的討論和對我的幫助。

　　廢話少說， 說個關(guān)鍵問題吧。 OO最常見的就是 Teacher.Students， Teacher.Speak(), 也就是說Students和動作Speak作為Teacher的組成部分， 是我們關(guān)注的切實存在的概念， 但傳統(tǒng)的OO居然沒有給出向*系統(tǒng)*描述這個概念的表達(dá)方式。 是的， 你我都理解字面意思Speak， 可問題是這個概念在系統(tǒng)內(nèi)不能表達(dá)， 我們就無法用其它機構(gòu)來處理這些概念。

　　為什么C#加入delegate以后， 方便了許多？ 因為Speak從某種意義上， 可以單獨提出來， 作為一個在系統(tǒng)中的實際存在， 并且開始可以對它進(jìn)行有限的操作了。但這還遠(yuǎn)遠(yuǎn)不夠， 因為Speak是作為Action()存在， 它自身在業(yè)務(wù)中的獨特性沒有特別好的方式去表達(dá)。

　　另外一點就是動靜間的鴻溝。 C#在Strustroup這些人的看法里， 并不屬于真正的靜態(tài)語言， 但是它給出了一個靜態(tài)的外表。當(dāng)我們進(jìn)行描述時使用的是靜態(tài)的方式， 我們就必須有靜態(tài)的方式處理它們， 否則這里面就存在裂縫。 如果大量的反射， 那么我們何必不直接使用動態(tài)語言呢？

　　JS大家都接觸過， 比如

　　obj["someAction"] = function() {}
　　obj.someAction()

　　那么C#拿著反射出來的MethodInfo搞來稿去，和JS的方式比丑陋的多， 這樣的方式有必要去學(xué)嗎？ 如果一門靜態(tài)語言， 大家越來越多的是在使用這些， 或者通過那些框架、工具間接的使用這些， 這難道說明這門靜態(tài)語言， 或者基于這門語言的OO方法， 越來越強大不成？ 只能說這種方法因為自身的問題， 無法繼續(xù)提供足夠的支撐了， 不得不求助于外部設(shè)施。

　　說實話， 如果一個語言， 表達(dá)重要的概念用到的那種表達(dá)方式， 比如類型， 它本身不能被操作的話， 那么它存在問題是必然的。 C#可以操作， 但提供的主要操作方式， 都在運行時， 通過反射。 可我們表達(dá)概念時， 卻在編譯前， 也就是說我們的表達(dá)注定是不完整的（或不直接的）。 反觀動態(tài)語言， 為什么越搞越火， 還不是因為人家干脆都放在運行時了， 完整了； 而且在表達(dá)方式上優(yōu)化過， 直接在語言層面支持， 這不是反射所能比的。

　　如果我每句話缺幾個字， 大家感覺如何？ 一個不完整的表達(dá)， 你覺得什么樣的工具或者方法論， 讓你能夠毫無障礙的完成模型的建立呢？

　　P.S. 再次感謝以上二位和與我討論過的各位。

　　另外， F#我也試過了， 這些問題全部存在(媽的，終于理解SICP某一頁的小注釋中質(zhì)疑流行語言的類型系統(tǒng)的原因了)， 根本是白搭： 實際上這本來與是否FP也沒啥聯(lián)系， 只是我希望作者按照腦袋兄跟我提出的那種意圖和方式， 在編譯器的層面做了一些改良。我的最后一線希望成了夢幻泡影。

　　我現(xiàn)在的建議是，要么選擇一門動態(tài)語言， 要么選擇C++和D(其實C++是個很差的選擇)； 如果暫時不能更換， 那就不要考慮太多了， 承認(rèn)問題的存在， 并且盡量彌補就是（似乎.NET平臺上的語言目前就是這種狀況， 我自己也是在鑒于現(xiàn)實原因沒法換的境地）。

　　Update：在這篇文章里似乎只針對了靜態(tài)OO不結(jié)合其它范式的情況下類型系統(tǒng)造成的麻煩，看起來統(tǒng)稱為OO的本質(zhì)缺陷似乎不妥。但實際上，避免了類型一棍子打死式的約束的、可以修改對象的語言只是把問題換了一個地方。它們的麻煩不同，但我初步認(rèn)為，在那個模模糊糊的深層次上，根源是相同的。

　　我在上面推薦動態(tài)語言，只是在針對目標(biāo)，問題僅僅存在在表達(dá)能力不足時的一個選擇。而且是不是動態(tài)了或者其它XX了，表達(dá)能力就完善無缺了，這也有待考證。這個問題容我思考一陣子再來掰吃。

　　另外，不要把結(jié)合了其它范式的OO混到這個問題里來看，能力來自于哪里，如何得到的，這是一個需要分辨的事情。更加多余的我想說的就是，是否存在概念或任何其它東西聚合的實例，這樣的東西就可以叫做OO了？那確實，如果把什么東西都當(dāng)成OO，OO這個詞也就利于不敗了。一個簡單的C Struct，你可以把它叫做對象嗎？如果可以，這就是OO了嗎？

　　所以我想，什么是OO，至少什么是OO的當(dāng)前環(huán)境下的解釋，還是要弄清楚的。之所以更新這段話，是因為參看了一些古老的爭論和某些高人高論的反復(fù)；覺得很多事情是在SB的基礎(chǔ)上，進(jìn)行各種NB的推論。這樣確實，周游世界的結(jié)果最終就是回歸原點，“返璞歸真”。也許我們覺得自己的思想境界提高了，但其實仍舊是一種屁話。

　　這樣的研討，除了應(yīng)該得到的，比如了解過的各種東西使用的更加流暢，就再無其它建樹了。因為該噎住你的地方仍舊在那里，僅僅是我們覺得“自然”了或者認(rèn)為這是“問題本質(zhì)帶來的復(fù)雜”罷了。而多少“自然”的東西最終不自然了呢？

　　最后重申一遍: 不要因為OO存在這樣那樣的問題， 就放棄OO的嘗試。 我的想法是， 作為一種當(dāng)代最流行的方法， 沒有一定程度的了解是不行的， 就像牛頓定律一樣。 所以我倒是認(rèn)為， 對OO的深入思考和練習(xí)， 雖然一時疑惑， 也絕非沒有好處的； 尤其是當(dāng)我們知道它可能存在問題這一點， 就更可以放開心態(tài)了。

　　過去一個高人對我說， 想學(xué)好數(shù)學(xué)先學(xué)好數(shù)學(xué)史； 我數(shù)學(xué)史不咋地。 今天我要說我們有一個大好機會， 因為我們就在歷史里（這個歷史看來還要持續(xù)幾年）； 如果我們認(rèn)為OO不過是個大忽悠，不屑于學(xué)習(xí)OO體現(xiàn)了自我相對于云云大眾的明智， 那么明天會如何， 就不好說了。

　　剩下的， 就是等腦袋兄的編譯器小改款出爐了， 大家一起拿鞭子抽他干活...

it知識庫：為什么OO方法是有本質(zhì)缺陷的？，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。