專案進入關鍵期了，最近乙個禮拜不斷加班寫**，回顧一年以來經歷過的專案，突然發現其實我們一直在追求的就是解耦，目的就是使自己的軟體系統能夠以更低的代價接受變化，比如增加新業務時，希望不用修改**或者少修改。
**級別的解耦是最常見的，把ooa/ood做的更好一些，每個類的職責明確，介面功能盡量細分，多使用經典的設計模式，這樣的**也比較容易看懂。
軟體一般都分層設計，比如1：資料層，2：資料加工**層，3：業務邏輯層，4：展現層，層與層之間也需要盡量解耦。按照mvc的思想，2、3屬於c。直覺中，乙個系統最少只需要資料層和展現層就夠了，2、3的作用就是控制流程，同時將資料提供者和使用者解耦，將來需要新增新的資料提供者和使用者時，只要符合2、3的介面要求，就可以做到插拔式的新增。這可以理解為模組級別的解耦。
業務級別的解耦需要產品設計和開發人員共同完成，
移動App開發中的View解耦問題
這幾天在做給ios 降耦的事情，順便嘮叨幾句開發中的view解耦問題。首先，我們先定位一下view的角色 view應該只操心前 後景色，字型屬性，布局特性，x y width height等純視覺屬性。不應該操心資料載入 修改，事件響應等model和controller關心的事。當然，也包括自定義的...
Egret開發筆記 七 解耦方式之，掛接解耦
需求 首先，需求是這樣的。戰鬥結算介面 就是戰鬥結束後會有乙個介面顯示這場戰鬥的得失 要顯示一些東西。這些東西並不是固定的，比如，今天有可能要顯示 國慶快樂 明天又是要顯示一幅圖。此處將會舉例顯示乙個元件，因為元件上可以放任何你需要顯示的東西。難點如果需要顯示什麼，就手動在這個介面上，加什麼。那麼後...
軟體開發中的併發
併發作用 1.在互動式應用中，快速響應使用者的請求，提高感知響應的時間 2.充分利用硬體資源，計算資源 3.簡化應用設計 併發壞處 1.難於測試 2.併發應用執行在複雜的環境下，軟體不確定性增多 3.處理同步，通訊的問題，增加程式設計複雜性 4.併發開銷對效能的影響，包括上下文環境切換，同步等 併發...