這段時間擺弄gae，對於python語言一直有點糊塗，看起來python作為較新的一門語言，對於物件導向的支援度較好，但是在《python核心程式設計》一書中，又看到python與ruby的比較，說明python並不是一門純物件導向的語言，而ruby是。這給我帶來一點困擾。
另外，我沒有做過基於cgi的純web服務程式，目前正在努力學習和理解這個程式的工作原理，這裡面也面臨了乙個問題，其執行模型為完全的響應請求型，即沒有請求，不工作，有請求，啟動乙個執行緒或子程序開始工作，這和原來做的伺服器，自己來組織執行緒的任務分配，有很大差異性，一時間，很難把物件導向模型套用進去加以思考。
以前我們討論過，軟體程式語言的發展，其實就是一部資料私有化的歷史。
以前做過很長一段時間的面相過程，面向過程的主體是函式，而c語言函式的出現，應該可以看做資料私有化的初步，因為第一次出現了函式內部變數，相對於組合語言而言，函式私有變數明確了每個函式執行體，擁有自己的變數空間，不再是所有變數都必須全域性，這給程式的安全性，帶來了很大的好處。
但這種設計，相對比較原始，只能解決部分問題。變數私有化之後，固然帶來了安全性，非授權訪問被禁止，但同時，也帶來了變數的「短生命週期」，即私有變數的生命週期，是和函式一起的，隨函式退出而死亡。
這在多工作業系統的平行計算中，給程式設計師帶來了很大的困擾。平行計算中涉及大量的等待同步，這期間執行緒執行生命體其實無事可做，作業系統為了**時間片，一般要求函式無事時及時退出，空閒出時間片給其他應用。這就涉及到現場保護問題。此時的函式，並沒有完成其業務，僅僅是因為等待而臨時退出，應該保留所有的中間變數，等待下次重入可以繼續手邊的工作。
這在c裡面帶來了很大的困擾，因為c只有兩種變數，全域性，和區域性，結果，程式設計師為了在函式臨時退出後，保留現場，被迫回到原始社會，重新使用全域性變數來做這件事，這就讓程式的安全性又退回了以前的水平。
所有的問題，其實歸結到一點，工程需求，需要部分變數在函式結束後，仍然保留等待後續使用，但又不希望使用全域性變數破壞程式的結構性。
於是，c++的面相物件思路出現了。我的理解，物件就是一堆資料和一堆方法的集合，在c++中，函式不再是程式的核心，即方**失效了。關鍵是資料，一切都是圍繞資料而存在，類和物件，為大家提供了乙個資料的長久儲存方法，函式反而由資料的擁有者，降格為資料的使用者。這就解決了變數的「長生命週期」和私有化保護需求之間的矛盾。
ok，理解到這裡，我好像有點領悟了。
gae中，我們的應用其實也分為兩個方面，不要苛求一定要面向過程或者物件導向。
對於乙個使用者請求，如果是私有訪問，與其他使用者資料不相干，則這個可以看做乙個純過程應用，即以乙個簡單的過程函式，來處理請求並回應即可。如乙個使用者修改其個人資料，完全可以作為乙個資料庫事務，過程執行，以函式方式程式設計。
對於某些公有性使用者請求，互相之間有資料互動，甚至可能影響其他使用者的訪問處理，則適合以該資料為核心，在內部構建資料物件，所有的類似使用者請求，全部訪問這個物件實現功能，採集結果回送，此時，以物件導向的類方式程式設計較為方便。
當然，物件的長期儲存，在雲計算中是個難題，不過這是另外乙個話題，也不是無解。
比如物件例項化的資料可以考慮放到資料庫中做永固性儲存，訪問類套用資料庫的資料實現訪問，但每個訪問類不要去摧毀資料，此時的訪問類有點類似「粘合劑」作用，將使用者請求的訪問行為，粘合到資料庫中的資料上，就比較簡單了。
一點想法哈，尚未得到驗證，請大家討論。
物件導向的方法操作memcache 面向過程程式設計
物件導向的方法操作memcache php操作memcache 第一步 例項化 mem new memcache 第二步 連線memcache伺服器 var dump mem mem connect 127.0.0.1 11211 mem addserver 127.0.0.1 11211 第三步 ...
物件導向過程與物件導向
物件導向過程與物件導向 1 程式的發展經歷了兩個階段 面向過程 物件導向。2 對於物件導向與面向過程可以用乙個例子解釋，如乙個木匠要做乙個盒子，那麼這個盒子的出發點會有兩種方式 物件導向 先想好要做的盒子，之後在去找相應的工具去做。面向過程 不去想要做什麼樣的盒子，隨需取工具。物件導向三大特徵 封裝...
物件導向與面向過程
分析出解決問題所需要的步驟，然後用函式把步驟分解開，使用時再呼叫這些函式。面向過程強調流程化 線性化 步驟化的思考方式 把構成問題事務分解成各個物件，描述各個事務在問題中的行為。強調整體性和差異性。具有抽象 封裝，繼承，多型 面向過程效率高 流程明確，具體步驟清楚 但耗費精力，重用率低 擴充套件能力...