1. 核心關註點 1.1. 開發軟體的原因 2. 切麵關註點 2.1. 所有的代碼領域都需要處理相關的問題 3. 結構化模式 3.1. 裝飾器模式 3.1.1. 可以在現有對象上添加新的功能，而不改變其結構 3.2. 代理模式 3.2.1. 所提供的對象可以替代客戶端使用的實際服務對象 4. 使用P ...
1. 核心關註點
1.1. 開發軟體的原因
2. 切麵關註點
2.1. 所有的代碼領域都需要處理相關的問題
3. 結構化模式
3.1. 裝飾器模式
- 3.1.1. 可以在現有對象上添加新的功能，而不改變其結構
3.2. 代理模式
- 3.2.1. 所提供的對象可以替代客戶端使用的實際服務對象
4. 使用PostSharp實現AOP
4.1. 收費軟體
4.2. 緩存
4.3. 日誌
4.4. 異常
4.5. 安全
4.6. 驗證
4.7. 事務
4.8. 資源池
4.9. 配置
4.10. 檢測
4.11. 推薦使用Castle
5. 異常處理
5.1. unchecked模式
-
5.1.1. 改善性能
-
5.1.2. 很多情況下unchecked模式並不會發生運行時異常
5.2. NullReferenceException
-
5.2.1. 防禦性編程
-
5.2.1.1. try {...} catch
-
5.2.2. 推薦實現ArgumentNullValidator
-
5.2.2.1. 推薦使用nameof(person)而不是對參數名稱進行硬編碼
5.3. 業務規則異常
-
5.3.1. Business Rule Exception，BRE
-
5.3.2. 符合預期的，並可用於控製程序的流程
-
5.3.3. 使用正常程式流程進行條件處理
-
5.3.4. 業務規則異常進行條件處理
-
5.3.5. 使用現有邏輯控製程序流程相比依賴拋出異常的方式顯得更加合理
5.4. 異常應當提供有意義的信息
5.5. 自定義異常
-
5.5.1. 提供更詳細的信息
-
5.5.2. 使用對最終用戶更加友好的術語
5.6. 異常類的名稱以Exception結尾
5.7. 由於異常導致方法無法完成時，應還原狀態
6. 線程與併發
6.1. 使用線程池
-
6.1.1. 令線程池決定線程的數目而非手動設置相應值
-
6.1.2. 任務並行庫（Task Parallel Library，TPL）
-
6.1.3. 使用ThreadPool.QueueUserWorkItem()
-
6.1.4. 使用非同步委托
-
6.1.5. 使用BackgroundWorker
-
6.1.6. 令線程池決定線程的數目而非手動設置相應值
-
6.1.6.1. 限制線程池使用的處理器數目及線程數目
6.2. 使用互斥量同步線程
6.3. 使用信號量處理並行線程
6.4. 避免死鎖
- 6.4.1. 當兩個或者多個線程執行並等待對方完成時就會發生死鎖
6.5. 避免競態條件
- 6.5.1. 若多個線程使用同一個資源，並由於各個線程的時序不同而產生不同的輸出，這種情況就稱為競態條件
6.6. 靜態構造器
6.7. 靜態方法
6.8. 可變性是多線程應用程式的問題之源
-
6.8.1. 創建後無法修改的對象稱為不可變對象
-
6.8.2. 為了確保線程安全，請不要使用可變對象，按引用傳遞參數或者修改成員變數
-
6.8.3. ImmutableArray
-
6.8.4. readonly struct
6.9. 線程安全
-
6.9.1. 傳遞不可變類型，而非訪問靜態成員變數
-
6.9.2. 在使用集合，通過引用傳遞參數以及訪問靜態類的成員變數時必須非常小心
-
6.9.3. 非線程安全的代碼，則需要用鎖或者互斥量以及信號量鎖定代碼
-
6.9.4. 在System.Collections.Immutable命名空間中的集合是不可變集合。
-
6.9.5. 保護資源訪問的另一種機制是使用信號量
6.10. 同步方法
-
6.10.1. 鎖lock
-
6.10.2. 在項目中引入System.Runtime.CompilerServices命名空間，併在需要同步的方法和屬性上標註[MethodImpl(MethodImplOptions.Synchronized)]特性
-
6.10.3. Interlocked類中的方法不會拋出異常
-
6.10.3.1. 無須使用lock語句以改善性能
