Java设计模式浅谈
话说java程序设计是一门需要经验的学问。
很多朋友对程序设计不屑一顾，编程嘛，实现你要的效果不就完了么？？！
其实不然，好的程序设计，能够作为一个积累，不管是代码、还是思想上的积累，都非常之重要。且不论工作时老板要求今天改改这块，变变那里。整理自己的思路才是最重要的积累。如果下次再需要做一个功能类似的东东。。。且不说完全能够照搬的可能性有多低，即使有，你调试程序，查看代码的时间也够让自己难受的---关键是这代码还居然是自己写的！那感觉，呵呵。不是好的程序员是体会不到的。
不是说设计好的程序，就必须学习设计模式。而是在设计程序的过程中，你会自然而然的想到一些方便的设计方法，这些，就其实是设计模式了。谁说设计模式只有23种，我说，设计模式是没有尽头的，没有办法用数量来限制的。也不要妄自菲薄，如果你在设计的过程中有一些的积累，形成了一个固定的做法去解决同样的问题，就是你的设计模式。
几乎所有的培训师、讲师、前辈谈起设计模式都会先问下，知不知道工厂模式，用没用过单例，然后给你举一些java api，或者很多显而易见的例子，然后再深入，海阔天空。。。没完没了了还。呵呵，只要动了脑筋了，想了办法了，能够有解决问题的方法，就且把它称为设计模式吧。
前两天设计了一个图片缓存的解决方案，没有什么设计模式。你不要说我也用了什么单例、工厂、观察者。。。我可能用了，但是我用的目的是解决问题，而不是去了解、熟悉、甚至吹嘘那些所谓的模式。
下面整理一下思路，图片缓存的设计方案，抛砖引玉。我一个人的思维肯定是受到我个人经验以及偏好影响的，必定有很多疏漏、不足之处，请大家一起来讨论讨论，共同学习。
1. 需求。
我需要制作一个对性能要求较高的网站，但是该网站的图片数量相当之大，如果想让客户得到更好的体验，就必须保证速度和过度的平滑。于是我设计了图片的缓存。
2. 思路。
图片缓存无非两种途径，前端和后台。我采取双管齐下的策略。
首先说说后台，我使用一个hashmap保存图像数据，使用文件路径和文件名作为key，考虑到图像的数量在2000左右，有可能在初期和后期图像数量相差比较大，所以采取了缓存大小可以配置的方法。当请求图像的时候，截获该请求，并获取图像路径，在hashmap中查找对应的图像是否存在，如果不存在，去磁盘上读取对应文件，并缓存到hashmap中，同时更新缓存的实际大小。如果当前缓存已满，从缓存中选择最久没有使用的一个图片，将其从缓存中去除，如果缓存大小还不能容下当前图像，再用同样的方法去除缓存图片，并将本图片缓存。考虑到实际磁盘中的图像有可能发生变化，并考虑到实际的性能，我设计了一种第一请求不更新的更新图片的方法。原理是使用一个线程去磁盘读入并更新缓存中的图像，这里就不论更新的图像大小比缓存中的大还是小了，hashmap能放很大。当一个请求过来时，我会查看所请求的这个图片在上一次请求时的时间是否是在指定的时间间隔内，如果是，不更新，如果超过了这个时间，那么就是说有可能更新了，所以开一个线程去更新这个图像。注意，这时图像是没有更新的，当下一次请求访问到来的时候，保证图像请求是最新的。这样就不耗费实际cpu资源的同时（如果开一个线程，每隔一段时间更新一次，就比较消耗资源），达到了更新图像的效果。如果每固定的时间更新一下磁盘文件，又每固定时间来一个请求，呵呵，那就永远拿不到最新的，哈哈哈。
再说说前台，javascript也有异步实现，呵呵，我使用了一个策略，页面上第一次显示的，正常访问，与之相关的，比如滚动图像等等，使用ajax请求图像（页面load完毕），并保存到缓存中（前台缓存），这时如果翻转图像、查看下一个，就会很快。呵呵。实现方法和后台缓存基本一致，只不过方式不同而已。
3. 效果及不足
第一次获取图像，因为涉及到很多判断，有可能比正常访问图像还慢一些，但是第二次开始就非常之快了，没有IO操作嘛。
有时间把代码传上来，呵呵，注释没写，现在不好意思拿出手。
很多朋友对程序设计不屑一顾，编程嘛，实现你要的效果不就完了么？？！
其实不然，好的程序设计，能够作为一个积累，不管是代码、还是思想上的积累，都非常之重要。且不论工作时老板要求今天改改这块，变变那里。整理自己的思路才是最重要的积累。如果下次再需要做一个功能类似的东东。。。且不说完全能够照搬的可能性有多低，即使有，你调试程序，查看代码的时间也够让自己难受的---关键是这代码还居然是自己写的！那感觉，呵呵。不是好的程序员是体会不到的。
不是说设计好的程序，就必须学习设计模式。而是在设计程序的过程中，你会自然而然的想到一些方便的设计方法，这些，就其实是设计模式了。谁说设计模式只有23种，我说，设计模式是没有尽头的，没有办法用数量来限制的。也不要妄自菲薄，如果你在设计的过程中有一些的积累，形成了一个固定的做法去解决同样的问题，就是你的设计模式。
几乎所有的培训师、讲师、前辈谈起设计模式都会先问下，知不知道工厂模式，用没用过单例，然后给你举一些java api，或者很多显而易见的例子，然后再深入，海阔天空。。。没完没了了还。呵呵，只要动了脑筋了，想了办法了，能够有解决问题的方法，就且把它称为设计模式吧。
前两天设计了一个图片缓存的解决方案，没有什么设计模式。你不要说我也用了什么单例、工厂、观察者。。。我可能用了，但是我用的目的是解决问题，而不是去了解、熟悉、甚至吹嘘那些所谓的模式。
下面整理一下思路，图片缓存的设计方案，抛砖引玉。我一个人的思维肯定是受到我个人经验以及偏好影响的，必定有很多疏漏、不足之处，请大家一起来讨论讨论，共同学习。
1. 需求。
我需要制作一个对性能要求较高的网站，但是该网站的图片数量相当之大，如果想让客户得到更好的体验，就必须保证速度和过度的平滑。于是我设计了图片的缓存。
2. 思路。
图片缓存无非两种途径，前端和后台。我采取双管齐下的策略。
首先说说后台，我使用一个hashmap保存图像数据，使用文件路径和文件名作为key，考虑到图像的数量在2000左右，有可能在初期和后期图像数量相差比较大，所以采取了缓存大小可以配置的方法。当请求图像的时候，截获该请求，并获取图像路径，在hashmap中查找对应的图像是否存在，如果不存在，去磁盘上读取对应文件，并缓存到hashmap中，同时更新缓存的实际大小。如果当前缓存已满，从缓存中选择最久没有使用的一个图片，将其从缓存中去除，如果缓存大小还不能容下当前图像，再用同样的方法去除缓存图片，并将本图片缓存。考虑到实际磁盘中的图像有可能发生变化，并考虑到实际的性能，我设计了一种第一请求不更新的更新图片的方法。原理是使用一个线程去磁盘读入并更新缓存中的图像，这里就不论更新的图像大小比缓存中的大还是小了，hashmap能放很大。当一个请求过来时，我会查看所请求的这个图片在上一次请求时的时间是否是在指定的时间间隔内，如果是，不更新，如果超过了这个时间，那么就是说有可能更新了，所以开一个线程去更新这个图像。注意，这时图像是没有更新的，当下一次请求访问到来的时候，保证图像请求是最新的。这样就不耗费实际cpu资源的同时（如果开一个线程，每隔一段时间更新一次，就比较消耗资源），达到了更新图像的效果。如果每固定的时间更新一下磁盘文件，又每固定时间来一个请求，呵呵，那就永远拿不到最新的，哈哈哈。
再说说前台，javascript也有异步实现，呵呵，我使用了一个策略，页面上第一次显示的，正常访问，与之相关的，比如滚动图像等等，使用ajax请求图像（页面load完毕），并保存到缓存中（前台缓存），这时如果翻转图像、查看下一个，就会很快。呵呵。实现方法和后台缓存基本一致，只不过方式不同而已。
3. 效果及不足
第一次获取图像，因为涉及到很多判断，有可能比正常访问图像还慢一些，但是第二次开始就非常之快了，没有IO操作嘛。
有时间把代码传上来，呵呵，注释没写，现在不好意思拿出手。
