如何在实际工作中发现模式（二）

５． 描述解决方案
        如果Forces描述非常吸引人，那么用户会迫切希望知道解决方案。软件开发人员通常希望采用图示法描述解决方案，因为一张图胜过千行字。然而需要注意的是，如果采用图示，一定要确保用户知道图示的含义。如果采用UML等标准的图示语言，一定要准确合理；如果是非标准的图示，一定要注明图例的含义。还需要注意的是，不仅仅要描述静态模型，还要描述动态模型。

        尽管图示非常有用，但仍代替不了文字描述。对图中的元素一定要进行适当描述，以避免对图的。很显然，如果不加描述，很难理解下图所表达的内容是什么。
                           
        这里使用的是组合模式？装饰模式？代理模式？还是未使用什么模式？

６． 效果
        对效果的描述是模式的另一个重要特点。需要注意的是，效果描述的不仅仅是使用模式获得的好处，更重要的是需要描述使用模式的代价。好处经常是显而易见的，而代价则经常被忽略。这些代价有时不仅仅是单纯设计上的代价，还需要考虑开发过程和成本。
        常见的代价如下。
（1） 复杂性提高，伴随复杂性提高的其他代价是测试难度增大，难以理解等。
（2） 对安全性的影响。
（3） 成本提高，如需要数据库支持等。
（4） 交互复杂，从而产生网络流量增加等其他代价。
（5） 对部署的影响。

７． 模式名称
        根据经验，为模式命名一个有代表性的名字并不是一件容易的事情。名称可能表示模式的结构，如“桥接”或“组合”。也可能表示模式的意图，如“抽象工厂”。也可能是模式的某个组成部分，如“生成器”。不管怎样，模式的名称非常重要，因为可以简化使用模式时的交流。

８． 模式的其他部分
        模式的其他部分包括“已知应用”、“相关模式”和“示例”等，这些同样是模式不可缺少的组成部分。如果你希望完成一个完整的模式，则必须包括所有这些部分。