应用Decorator模式的一个很好的实例

　本文转自板桥里人 

     本文从一个案例分析设计角度，讨论了使用设计模式可以比较优雅地实现了质量、功能和性能的统一。很多人以为设计模式是抽象概念，实际上，设计模式是实战经验的总结，只有正确使用了设计模式，才明白设计模式真正的运用技巧，避免了过分设计或设计不足。

　案例需求和问题

　　多个图片上传是很多系统的基本功能，一般图片是一个主体父对象的附属，如是商店的图片、是人物的图片。以下商品Product为例。

　　一般一个商品Product有多个图片Image，他们是1:N关系，表单中图片的处理不同于文字，用户需要将图片专门实现上传后，后台服务器系统必须接收和处理这个图片， 有两个办法：
　　(1). 首先直接保存到数据库，等Product保存时，再将两者1:N关系保存数据库中；
　　 这个方案的缺点是：如果用户上传图片后，不再继续Product操作，那么，数据库中就有很多垃圾图片，这些图片找不到宿主Product。

　　(2). 图片不保存到数据库，先暂存在内存中，等Product其它文字属性字段保存时，同时存入数据库。这个情况将图片视为文字一样普通字段，比较符合实际流程。

　　第二个方案可以将图片保存到HttpSession中，带来一个问题：用户上传图片后，有可能需要删除，图片有可能是用户刚刚上传，保存在HttpSession中，也可能是在数据库中（修改商品数据时，同时希望更换商品的图片，而这时图片是从数据库中获得的）。

　　面对这个问题，很多人认为比较简单，将HttpSession和数据库都视为数据源，同时新增或同时删除，如下图：

　　　　　　　　　　图1

　　在整个图片上传功能中，涉及到几个功能类：
　　首先是图片列表功能类，用来将HttpSession和数据库中当前Product下所有图片显示出来；
　　其次是图片上传功能类，显示一个图片上传界面，然后接收上传的图片。
　　最后是每个图片的显示功能类，每个图片需要专门的功能类处理才能显示。

　　上述三种功能类都涉及图1的操作，也就是说，这三种功能类中都要和两种数据源打交道。

　　还涉及到另外可扩展性问题，现在图片缺省的宿主是Product，以后可能是Person或其它任何需要图片的对象，因此，在这种设计中，我们必须重用图片上传功能。

　　但是，矛盾在于，数据库一般是和具体宿主对象Product有具体联系的，在图片上传功能中必须和数据库某个具体数据表读取数据或写入数据。如何实现图片和宿主的解耦？

　　现在，复杂问题出现了，由于加入功能类增多以及重用解耦的要求，使得图片上传功能的代码实现变得复杂。类图关系如下图：

 

图2

　　很显然，这种调用关系非常纷乱，可扩展性很差，如果我们增加新的数据源，例如，由于图片文件都很大，因此我们经常采取缓存技术，这样提高图片显示速度，这种显示速度不亚于系统从文件系统中读取图片文件。如果加入缓存，那么所有的功能类都要修改一遍。

　　更重要的是，图2丝毫没有给出将宿主和图片解耦的思路，反而是理还乱。很多人的思维停在这里就没有前进了，本着够用就好，KISS或愚笨原则，就会按照图2思路实现代码，这样下去结果是非常可怕的，通常陷入头痛医头、脚疼医脚的问题，测试人员只有测试到了这个系统的BUG才去修改，但是很多情况下，这种设计错误是无法靠测试来纠正的，因为测试不可能穷尽所有实际操作。这也是很多软件系统不稳定、BUG永远清除不了的原因之一。

      解决之道

　　我无法总结图1是如何跳跃到图3的（可能是对此类应用的本质了解和模式理解），但是，我们可以知道，图3给我们思路重新打开了一道门：

图3

　　 我们把HttpSession和数据库不并列起来，而是串行，这样HttpSession好像是数据库的过滤器Filter或代理，这样如果有Cache机制加入，实际就是在HttpSession和数据库之间再加一个filter。

　　 在这种情况下，如果你熟悉GoF的23种设计模式，应该可以发现图片上传功能中可以使用设计模式了， Decorator模式是我们推荐的。

图4

　　 图4显然要比图2清晰得多，同时似乎一劳永逸解决了伸缩性和扩展性问题，具体Decorator模式实现代码这里不罗列，在各个功能类中调用Decorator模式的代码如下：

ImageFilter imageDbFilter = new ImageProductDbFilter();
ImageFilter imageCacheFilter = new ImageCacheFilter(imageDbFilter);
imageFilter = new ImageSessionFilter(imageCacheFilter);

　　 从调用代码看，图片上传功能已经可以重用，因为，对于不同的宿主，只要将ImageProductDbFilter()更换为ImageItemDbFilter()就可以了。

　　 如果将上述代码写为：
imageFilter = new ImageSessionFilter(new ImageCacheFilter(ImageProductDbFilter()));

　　 联想到Ioc和依赖性注射进而AOP，是不是可以对于不同的宿主应用，将具体ImageProductDbFilter()之类实现子类注射到这个图片上传系统中，就可以实现不同应用的图片上传功能？

　　 至此，以后的方向更加清楚了，应该是如何使用AOP或Ioc模式将图片上传功能重用提炼到框架中了。

　　本文最终想表达的是：设计模式为我们开启了一扇正确的解决之门，从此我们的系统发生了质变，从程序员自觉朴素的代码走上了和软件设计思想发展方向一致的宽广大道。

　　因为你已经将你的系统或模块纳入了一个软件理论体系中，这个理论体系一直在发展，你的系统或模块将会随着体系发展而有永久的生命力。你的问题不再是孤立的问题，也不再是特殊的问题。

　　我的个案如我的孩子一样，我喜欢将我的个案纳入一种体系或标准中去，自此，他就有了发展和可参考发展的余地了，他就有生命了。

（完）