面向對象的運行時特性分析+面向對象與內存

相對於面向過程的開發方法，面向對象經過退一步，海闊天空。最頻繁地用來表達人類認知或描述的天然語言中的主謂結構在面向對象的形式系統中獲得充分的映射。這種形式系統具備極大的語義構建能力。我甚至可以想象若是加上模糊邏輯的應用，任何系統的構建都將不成問題。由於它幾乎具備完美的語義構建能力。若是再加上啓發式搜索，恐怕連強人工智能也不是沒有可能的！

傳統的開發方法在其形式系統的語義表達能力上存在的極限被稱爲語言鴻溝，由於從那些系統到天然語言間存在巨大的GAP。面向對象經過填平這個鴻溝，完全地解決了計算機形式系統的表達問題。緣由是其具備很是強的認識論基礎：對象。因此，說哲學沒用的真的是值得好好反思。沒有哲學的話，有哲學的話，差異不是通常的大：人類正常認識的途徑是向前看。哲學是向後看。方向不一樣，看到的東西就不一樣，結果天然就不一樣。

可是這是從開發方法的角度所討論的面向對象。也就是說，它的確是一種很是好的開發方法。它固然同時也是一種很是好的建模方法。這更進一步意味着使用它所構建出來的系統與真實「世界」將更接近（由於它與人類語言的表達方法更貼近。而「世界」其實存在於語言中）。這種模型（人腦模型與計算機模型二者）上的一致性給我帶來一種莫大的安全感與溫馨感，由於：

1，運行時變得很是透明且很是容易理解。系統運行時對我來講不再是不可捉摸的了。我做爲一個系統的「讀」者，將再也不承擔在形式系統與天然語言即人類知識模型間的翻譯工做。由於面向對象的系統完全移除了形式系統與人類語言間的語言鴻溝（至於在當前編程語言中仍然存在的部分語義學問題，它本質上實際上是一個語言問題，不是面向對象方法論的問題。它存在，是由於語言的設計者或編譯器的設計者沒有承擔他們應該承擔同時也只有他們可以承擔的責任------大部分這類問題都是一種服務問題，而服務固然是語言的問題。好比volatile問題，它原本屬於語言自己應該內「涵」的服務而不該該以一種語法元素出現），實現了（即形式化了）幾乎所有的語義元素，我能一眼就看出系統當前的狀態。由於系統如今有狀態了而且狀態就擺在那裏（面向過程的系統沒有狀態。要了解這種系統的狀態必須將大腦中沒有被形式化的主語與畸形的形式系統結合起來而後通過大量思考才能獲得---套用一句時髦的話：這「不夠人性化」）等着我去看；

2，基於對象的運行時系統更「緊湊」。這個緊湊的意思不是指系統構件之間的依賴意義上的緊湊，而是指系統規模上的緊湊。由於不少在認識論上處於「對象」以上的語義元素如今都隱藏（被承載）在對象間的實時（動態）交互上，而不是靜態關係上，因此其靜態結構天然更加「緊湊」。一個更小的系統規模一般意味着更小的理解與記憶負擔；

3，As long as I can keep all of the objects in good status, theoretically, the system will always be in good status too. This is apparently one very good way, at least one of the very good ways, to achieve high system stability. I mean, what I can do to make a Process Oriented system stable?... I will always  be worrying about it!

4，面向對象的系統更容易被驗證。這種被驗證性來自於其形式上的完整性。相比之下，面向過程的系統因爲其形式上的不完整性，則基本不具有被進行形式驗證的條件。由於它不是一個完整的系統，系統的另外一半位於程序員的大腦中。而誰能驗證一我的的大腦？

我不想說面向對象有問題。由於它實在是太完美了。但經驗告訴我，越是完美的東西，來到真實世界越可能有問題。如今就來看看它到底有什麼問題。

面向對象的對象所有生存在內存中。這要求程序員具備很是強的內存編程技巧。有人可能認爲程序員一直都在對內存編程，怎麼可能出問題。答案是非也。由於大多數程序員在作的事情中，大部分其實並非對內存而是對數據庫編程。對數據庫編程與對內存編程存在巨大的差別。其中之一就在於數據庫是一種很是成熟的技術，它對服務的封裝很是良好，以至於即便傻瓜也很難在數據庫編程上犯錯誤。但內存編程徹底相反。內存編程要求程序員一針到底，直搗黃龍。程序員在進行內存編程時須要直接處理內存（這本不該發生。可是面向對象每每意味着比較複雜且難以用關係模型處理的問題域。也就是說，面向對象常常用來處理的並非普通邏輯而是特殊邏輯。而這種邏輯或問題一般沒有現成的方案，必須在裸機上自行建模才能解決）。緣由是如今所謂的高級語言其實並不高級，它們大多隻不過是機器語言的直接翻譯而已（包括運行在虛擬機上的語言）。使用這種語言進行編程與在機器上直接編程其實沒有本質上的區別。由於陳述的層次並無絲毫的提高。好比「變量」只不過是對內存地址的一個別稱而已。包括「賦值」與「循環」這樣的語義，它們仍然是機器級別的語義，離機器基本上都是0距離（語義上的）。

在機器上編程要求理解並能控制機器。這對於應用程序程序員固然是一個問題。並且是一個很大的問題。程序員有問題，老闆便天然也有了問題：老闆被逼迫聘請經驗更豐富的程序員。這提升了軟件開發的成本。得，一分錢一分貨，使用面向對象之後，質量是更好了，但價格也更高了。因而那些無狀態的編程方法便跳入了眼簾。

如函數式編程由於剔除了變量，使得系統中果然只剩下純粹的「計算」（「計算機」終於名符其實了）。這樣的結果是，系統只能提供一種語義：計算。這種語義服務比面向過程的語義服務顯然更加乾淨利索。由此也能夠看出，它將擁有比面向過程更大的問題：它把一切都當成了計算。這比面向過程的把一切都當成過程錯得更離譜，更遠。所以它不是解決方案。一個可能的方案必須是一個至少去除了全部的同步語義但保留了面向對象語義承載能力的形式系統。FP把狀態都剔掉了，對象如何可以「存在」？？

爲了提升產品質量或開發難度而把狀態剔除掉，與倒洗腳水連孩子（或別的東西）一塊兒倒掉是一個道理。

I mean, if you're really developing some kind of systems which are really only about computing or calculation, then FP is the best choice. But that is obviously not all the cases. For example, what you can do with FP when you're required to design a realtime multiplayer game? ...

語義轉換是很困難的。形式系統能夠工做，是由於咱們給它賦予了與它的天然特性相符合的語義。語義替換固然是可能的，但那並不能在全部情形下工做。事實上，根據語義自己的精確性，在絕大多數狀況下的語義替換都不是徹底可行的。至於具體的可行度，則由語言做爲一種形式系統其解釋者的容忍度決定。

由此能夠看出，也許不久的未來面向對象對於大多數程序員將再也不是問題，但至少目前仍然是個問題。

對程序員的高要求只是一個方面。還有一個方面是內存容量。前面提過，面向對象的系統是緊湊的系統。但這種緊湊只是指其靜態結構上的緊湊，不是規模上的緊湊。由於對於那些須要大量對象的系統，系統將可能很容易就達到很大的內存規模。事實上，這正是目前許多面向對象系統的當前狀態。在這樣的系統中，適當地實施必定的持久化策略（不是緩存。由於緩存是一個以持久層爲中心的概念------它不屬於面向對象範式中的詞彙）就顯得頗有必要。能夠考慮將這樣的系統放在一個提供持久化服務的容器中（如EJB容器）。

面向過程。。過程的形式化語義==計算，，，「計算」機？，，。運行時語義？