想了想， 還真不知道拿什麼題目起頭。 這樣， 從以前的文章開始好了。
為什麼oo是有本質缺陷的？
這篇文章中的疑問首先有這麼一點： 靜態語言中，我們如何能在改變乙個系統內部介面的時候（注意， 不是對外發布的， 所以沒有不能更改的問題）， 只更改一處就解決問題？ 比如最簡單的， 乙個類， 有name屬性， 是string的， 它對應某乙個資料檔案裡的類似於表中一列的資訊。 改變資料檔案的結構，新新增了乙個叫做description的記錄資訊， 乙個內部實體也增加了這個屬性，我如何做到不修改從資料檔案中讀取， 和寫入資料檔案的**呢？
畢竟， 這兩個屬性對這個資料檔案的讀寫， 是沒有什麼差別的。舉乙個對比的例子， 在c++中， 我可以這樣：
fields
typedef map
<
fusion::pair
<
fields::name, std::
string
>
, fusion::pair
<
fields::age,
int>
, fusion::pair
<
fields::code,
char
>
>
person;
使用時，我們這樣使用：
person a_person;
at_key
<
name
>
(a_person) =s;
at_key
<
age>
(a_person) =i;
at_key
<
code
>
(a_person)
=ch;
事實上， 這是使用fusion，稍微更改一下形式， 就可以變成這樣： a_person.p, a_person.p。如果碰見變化， 修改一下typedef即可。 而我操作person的**，只要其本身的邏輯沒有變化，就可以做到一字不改； 因為我可以通過獲取map中所包含的型別定義攜帶的資訊， 直接寫乙個統一化的過程， 進行所有操作。 而如果使用oo， 第乙個可以想象的就是， 每乙個倒騰資料的邏輯， 無論是從哪兒到哪兒， 我都得加上對該屬性的操作。
這個最大的好處是，只要在本質上是相同的過程， 我們只用寫一遍。 另乙個好處是， 我們同時具有靜態語言的全部優勢： 比如沒有定義和包含description的時候， 無論你是at_key，還是a_person.p，根本就不會通過， 這樣在非常大量的這種工作， 比起dictionary和動態語言， 我們就可以避免大量的失誤。
我想， 這個問題不能簡單的用「很少有人用」來回答，因為它是結果。 首先它是方便的，而且方法名、屬性名這種給人使用的死標記沒有的缺陷它也沒有。 那麼我認為，沒人用更多的僅僅是因為， c++和另外那些支援這種非oo正規化的靜態語言，其它地方太爛，是首先否定了語言上的選擇， 所以也就沒人在實體上使用這種設計和實現的方式。
當然使用dictionary就痛快多了， 不過強型別帶來的保障沒了，這是不是缺陷呢？還可以使用反射完成相同的功能， 然後付出效能， 在我看來，這個效能就是缺陷的證明； 比如： 資料來源是資料庫， 那麼有的orm就用反射完成類似的工作， 但orm的存在，反而證明了需求的存在。而且在orm覆蓋範圍以外的資料複製和轉移呢？ 效能問題， 我們可以通過emit來解決， 但emit不是適合於所有使用情景； 而且， 我們就必須編寫和除錯大量的emit**， 額外的設施的使用和多付出的工作量， 也是缺陷的證明之一。
畢竟， 這些資訊本來就是執行前已知的， 而且他們是有規律的， 也就是可以通過某種形式在執行前處理的， 同時可以通過合理表達自動化的。某人嘴裡的「孟老頭」對這個事情有他自己的理解， 現在就看某人的啦： 這是不是oo的缺陷？
jquery的一些疑問和解答 待擴充套件
一 fn是指jquery的命名空間，加上fn上的方法及屬性，會對jquery例項每乙個有效 1 jquery.extend object 為jquery類新增新增類方法，可以理解為新增靜態方法。2 如擴充套件 fn.abc 即 fn.abc 是對jquery擴充套件了乙個abc方法,那麼後面你的每乙...
Nosql的一些疑問
couchbase,membase與memcached的關係是？我了解memcached是什麼，但是不知道前面2者與它的關係是什麼？就我的理解，好像前面2者只是提供了乙個memcached的管理頁面？其實還是memcahced的東西？另外，為什麼couchbase的安裝包90m，而memcached...
我的一些疑問
1.每丟擲乙個異常，就自動生成錯誤碼並持久化，即執行時生成錯誤碼，這樣可以提高錯誤碼的定義效率 2.國際化自動生成工具，給頁面自動生成國際化的主鍵，然後可以提取所有的主鍵進行統一的編輯 3.校驗 4.系統統一資源管理 有的多執行緒實現是為了非同步，有的多執行緒實現是為了併發 有的多執行緒實現需要盡快...