設計模式
什麼是設計模式
- 設計模式是人們在開發中遇到的共性問題而提出的一個解決方案
- 比如說：孫子兵法中的各種策略其實就是針對某種情況的經驗總結
- 程序開發中的設計模式只是一種參考，而不是一成不變
常見設計模式
- 簡單工廠模式(典型應用：解決單一對象創建的擴展問題)
- 抽象工廠模式(典型應用：解決多種類型數據庫訪問問題或不同業務邏輯)
- 單例模式(典型應用：在WEB開發中，設計購物車的時候)
現實開發中遇到的問題
- 某個項目中需要一個打印報表程序，但是該項目的用戶可能使用多種報表形式，比如有些企業使用Excel報表，有些企業使用直接設計報表，有些企業使用Word報表，還有些企業可能使用其他報表組件
- 項目要求設計至少三種報表模塊，項目發佈後只需要修改一下配置信息則即可滿足不同用戶的報表需求
解決方案
- 因爲設計到系統問題，考慮使用接口設計報表模塊
- 同一個需求有不同表現，符合多態的應用條件
簡單工廠模式
簡單工廠模式的原理
- 工廠通過“選擇”的方法來指定應該創建哪個“接口實現類的對象”
- “工廠”其實就是一個對象創建的方法，讓對象“延遲創建”
簡單工廠中存在的問題
如果用戶的需求再次提出來更新，要新加其他的報表類型，需要修改工廠中的代碼，違反了面向對象中的“開-閉原則”
反射技術
概念
反射(Reflection)是.NET中的一個重要的技術，通過反射，可以在運行時獲得某個類型的各種信息，包括方法、屬性、事件、及構造函數等，還可以獲得每個成員的名稱等信息
特點
在程序運行時，動態創建對象、調用方法、設置屬性、激發事件，而不是在編譯的時候完成
反射的應用
- VS中的只能提示、使用MSIL反編匯工具查看IL代碼都是使用反射技術
- Java開發工具Eclipse中的插件使用也都是反射技術
開發中的應用
- 系統需要基於插件開發的時候，必須要使用反射
- 在簡單工廠和抽象工廠設計模式的時候需要使用反射技術
- 使用反射一般都要配合接口的使用
- 反射技術使得系統性能有一定程度的降低，除非是必要情況，否則不宜使用過多
接口框架
基於接口設計三層架構
開發團隊協作保障
- 項目命名、模塊命名、類編寫要求規範、註釋要求…
- 數據庫設計規範：表的命名、實體屬性命名、約束…
- 項目開發中協作的形式：垂直分工、並行開發。
垂直分工:
- 任務分工：按照功能模塊
- 技術要求：要求開發人員必須要熟悉項目各模塊(DAL/BLL/UI)編寫
- 應用場合：中小型項目，且開發團隊力量比較小
- 現實比較：類似於小企業的“作坊式”生產
並行開發：
- 任務分工：按照軟件的實現模塊(業務邏輯、數據訪問、視圖、通用…)
- 技術要求：要求開發法人員只需要熟練掌握自己對應的模塊技術
![在這裏插入圖片描述]()
硬件接口應用
接口設計和產品生產
- 硬件接口的應用使得不同廠商可以專注生產自己最擅長的產品
- 產品的組成=不同的硬件接口+接口產品
接口的任務控制所有的產品廠商生產的產品是保持有同一的一個接口，讓廠商更專注於自己的產品質量問題，不需要糾結通用的一些問題
接口三層優點和缺點
優點：
- 很好的解決並行開發中的團隊協作問題
- 系統的可擴展性進一步增強，當增加新的功能點時，接口層和實現層可以輕鬆的同步修改，各自完全獨立工作，互不影響
- 適合於項目較大和開發人員較多時採用
缺點：
- 增加框架的設計難度和開發的工作量
- 項目較小時不宜採用
基於接口設計、除了三層架構之外其他架構設計也完全可以使用
接口的使用與否，取決於開發團隊和項目的實際需求，而不是爲了使用接口而引入接口
開發中框架的選擇
基礎框架
小型項目、功能簡單、個人開發，項目週期短
兩層框架
小型項目、功能稍多，個人開發或團隊開發，項目週期適中
三層架構
大、中型項目，功能多，專業團隊開發，項目週期長
接口三層
大、中型項目，功能繁多，專業團隊並行開發，項目週期長