５． 描述解決方案
如果forces描述非常吸引人，那麼使用者會迫切希望知道解決方案。軟體開發人員通常希望採用圖示法描述解決方案，因為一張圖勝過千行字。然而需要注意的是，如果採用圖示，一定要確保使用者知道圖示的含義。如果採用uml等標準的圖示語言，一定要準確合理；如果是非標準的圖示，一定要註明圖例的含義。還需要注意的是，不僅僅要描述靜態模型，還要描述動態模型。
儘管圖示非常有用，但仍代替不了文字描述。對圖中的元素一定要進行適當描述，以避免對圖的。很顯然，如果不加描述，很難理解下圖所表達的內容是什麼。
這裡使用的是組合模式？裝飾模式？**模式？還是未使用什麼模式？
６． 效果
對效果的描述是模式的另乙個重要特點。需要注意的是，效果描述的不僅僅是使用模式獲得的好處，更重要的是需要描述使用模式的代價。好處經常是顯而易見的，而代價則經常被忽略。這些代價有時不僅僅是單純設計上的代價，還需要考慮開發過程和成本。
常見的代價如下。
（1） 複雜性提高，伴隨複雜性提高的其他代價是測試難度增大，難以理解等。
（2） 對安全性的影響。
（3） 成本提高，如需要資料庫支援等。
（4） 互動複雜，從而產生網路流量增加等其他代價。
（5） 對部署的影響。
７． 模式名稱
根據經驗，為模式命名乙個有代表性的名字並不是一件容易的事情。名稱可能表示模式的結構，如「橋接」或「組合」。也可能表示模式的意圖，如「抽象工廠」。也可能是模式的某個組成部分，如「生成器」。不管怎樣，模式的名稱非常重要，因為可以簡化使用模式時的交流。
８． 模式的其他部分
模式的其他部分包括「已知應用」、「相關模式」和「示例」等，這些同樣是模式不可缺少的組成部分。如果你希望完成乙個完整的模式，則必須包括所有這些部分。
如何在實際工作中發現模式（一）
前提 模式的發現是可遇不可求的，既然是發現，就有機會的成分存在。不可能當我們希望發現模式時就一定能夠發現，困此發現模式的第 個前提是不要為了發現而發現，這樣你會失望的。然而，機會從來是被有準備的人抓住的。重構原有的專案 學習同行的經驗和總結是發現模式的最好時機。需要強調的是，不僅僅只有設計模式，分析...
如何在實際工作做開展效能測試
回答 從小入手，從簡單的開始，然後慢慢的做更系統更複雜的效能測試。剛接觸效能測試的同學往往不知道效能測試是有需求的。比如 如果你是效能測試同學，假設時間有限，這兩個需求你只能接乙個，你是接哪個？很多同學會選第乙個，因為第乙個需求似乎是效能測試的需求，第二個跟效能測試似乎沒有特別強烈的關係。但是第乙個...
FTP的兩種模式和在實際工作中應用
ftp是一種檔案傳輸協議，它支援兩種模式,一種方式叫做standard 也就是 active,主動方式 一種是 passive 也就是pasv,被動方式 standard模式 ftp的客戶端傳送 port 命令到ftp server。passive模式ftp的客戶端傳送 pasv命令到 ftp se...