1. 最早的單例式框架
正如魯迅所說 「世界上本來沒有路，走的人多了，也就成了路」。as3剛剛問世時，幾乎所有公司的筆試題中都要問及單例模式。那個時候也就無所謂什麼框架解耦的概念，小點的程式根本就沒有框架和設計模式之類的概念，大一些的就是一堆單例之間互相呼叫。
2. mvc模式的侷限性
但這種模式存在著一定的侷限性，只適合做比較小型程式，一旦程式複雜，就會出現難以避免的問題。具體情況如下：
1）. view的重新整理的model中資料變更所導致的，而model個體則是對具體程式角色屬性的集中儲存。
2）. 複雜程式由多個model和多個view組成，且乙個view可能要關心多個model中的不同資料項。
3）. 一條程式邏輯（command）可能需要改變若干個model中的資料項。
由於上述三個問題的普遍存在，一條程式邏輯可能造成幾個view重新整理幾次，這樣造成的結果就是：程式複雜度公升高，邏輯分支混亂。程式可控性降低，bug難於排查和定位等等。
此外，mvc模式還出現了一些變種，由於大多數程式邏輯由i/o操作導致，因而越來越多的程式將command中的邏輯封裝到了view中，淡化command的工作甚至棄用。
隨著人們對mvc模式認知的不斷深入和成熟，以及mvc模式的固有缺陷，mvc框架應運而生。
3. mvc框架
mvc模式的框架，最具代表性的就是cairngorm 和puremvc了。cairngorm 是adobe官方推出的as3程式框架，較好的演習了mvc的設計模式，而puremvc則是當時最為成熟，最為程式設計師認可的as3框架。
cairngorm 官方demo（兩個三角形（也可以想象成兩隻小老鼠）進行追逐的那個demo）側重於在command中實現邏輯，puremvc則把重頭戲放在view部分（訊息通訊中樞，即全域性被觀察者單例就位於view單例當中！），而且在它的程式結構圖中還畫出view模組下有許多ui子模組，這符合「盡量將子系統自身的細節和複雜性隱藏在子系統中」的封閉性原則，又叫閉包原則。
把每條具體遊戲行為寫在command中，便於重用。即：在任意地方想要執行某個邏輯，只需要發訊息即可。但這會產生大量的冗餘**和工作量。不但不便於程式的除錯和問題排查，而且想要知道所觸發的這條邏輯何時完成，完成的結果如何以及是否是這段**觸發的，都變得困難，由此導致邏輯不可控。
puremvc側重於將執行邏輯寫在mediator中，或一些閉包的邏輯直接在ui模組內部實現。puremvc之所以比cairngorm 更受追捧，是因為puremvc已經有了向mvp方向轉型的萌芽。雖然puremvc也有command這個類，不過乙個明智的開發者是不會使用的。
puremvc和cairngorm 開始時是單例核版本的，隨後都推出了多核版，但對於如頁遊（webgame）這樣的大型互動應用，無論是在功能上，還是在效能上所產生的意義並不是很大。
4. mvp框架
puremvc和cairngorm 雖然做到了程式模組化和解耦，但冗餘**過多等因素逐漸引發了開發者的不滿。隨後，各種框架如雨後春筍般頻繁出現，有的側重於輕量級和**簡潔，有的側重於整合ui表單，有的則側重於物理系統運動學等常用功能的封裝，還有大而全的傳統型**庫....。逐漸出現了百家爭鳴的盛況，但可惜的是並沒有出現乙個能徹底替代puremvc和cairngorm的框架。
就在這個時候，市場上出現了頁遊井噴潮，各大頁遊廠商成了as3的重要舞台，他們的框架基本上都是由puremvc或cairngorm衍生出來的，每個公司的業務不同框架也就各有側重。這個基本上都是每個公司的核心技術，本人的了解也就只有我工作過的幾家公司了，不足以說明整個行業的情況了。
由於智慧型手機的崛起等市場因素，作為技術頂峰的頁遊市場也江河日下市場份額不斷縮小，後來as3也是後勁不足，最終頁沒有自然孕育出乙個非常經典的mvp框架，上圖是我自己的mvp框架結構圖。
5. 關於mvvm模式
關於mvvm，早在flex2.0（或更早）就引入mvvm模式，並且支援css。這種模式有其自身的有優點，如：
1. 開發效率高，比mvc、mvp模式的開發效率都要高，幾乎沒有冗餘**，**簡潔，可讀性高。
2. 封閉性強，將資料直接寫到view中，大大提高了封閉性從而**可讀性也大大提高了。
3. 支援css，便於樣式的復用，提高**可讀性。
但是這種模式並不適合遊戲等複雜邏輯應用，我認為有以下下幾點理由：
1. vm這種結構本身有一定的侷限性。遊戲中有許多資料都是公用的，而vm作為乙個閉包，最優方案是將資料移入到view中，這樣就難以兩全其美,要麼破壞vm的結構增加資料耦合性，要麼就需要在**邏輯中對同一資料的多份副本同時分別進行維護，這樣勢必造成架構上的缺陷和不足。
2. 資料繫結的問題。資料繫結是可以繫結函式的，這樣會多出來許多getter函式的呼叫，即便ui不需要重新整理也會引發呼叫，並且重新給view賦值，即便資料還是和原來一模一樣的，這個時候view是否重新整理就不一定是應用層**能控制的事情了。
我印象中的 多型結構與類結構
繼承 多型 封裝 如果乙個包內的類有著一些聯絡來互相呼叫，我們為了資料安全，也就是被其他類不小心訪問到修改，會對類的成員方法 成員變數進行封裝，也就是 對變數進行修飾 私有化 privter 並為他們提供使用的介面方法，這些方法就是get set方法，類內的功能也因為功能 行為 的不同封裝為乙個乙個...
SEOer發展過程中的五道檻
seoer發展過程中的五道檻 下面是kyw在不同時期的心理變化 本文說心理狀態，不說seo技術 第一道檻 剛接觸seo的時候 心理特徵 第二道檻 第乙個案例不知道為啥排名還不上去的時候 心理特徵 1 迷茫 kyw的第乙個案例是，當時根據教程，把能優化的方法都用上後，就天天更新，想著排名會上公升。但2...
2 小公司發展過程中「強人」的重要地位
小公司發展過程中 強人 的重要地位 首先宣告 小 和 強人 是相互對比的概念，在人才濟濟的一流公司裡，原來可以稱為 強人 的人首要任務就是做好 普通 的事情。曾經的中關村的軟體公司，乙個人，兩三個人的小公司非常多，他們只有乙個產品，乙個人的生產線只有一條，渠道狹窄，導致無法承受任何的 風吹草動 這時...