如何在实际工作中发现模式(二)

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

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

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

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

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

你可能感兴趣的:(工作)