Java 程序员们，你们的设计模式知识怎么从书本走向实践的？

多读源码，无它

尤其是当你读到到一种模式被应用在数种不同场景时，会有一种豁然开朗的感觉
比如，当你弄明白了servlet filter的工作原理，再去看aopalliance的MethodInterceptor与MethodInvocation，会发现它们的设计如出一辙，心中大呼“卧槽！这就是chain of responsibility”

看的多了自然就会用了

想要实现某个功能结构或了解底层代码，看所谓的框架的源码的时候，发现原来我擦，它这里是用这种方法是这么处理的，虽然此时根本不知道这叫啥模式~~

遇到某个项目，要自己去架构的时候或者有棘手的问题的时候，在寻求解决方案的时候，突然想到以前看到的 “XXX模式”，“XXX方法” 好像是可以解决的~然后问题就被解决了。

多看代码，写的每行代码都要思考。。所谓思考不是按照逻辑去考虑。是跳出来，站在最抽象的位置考虑。几年以后，设计模式就是个笑话了。。
设计模式只是个名词，核心是解决问题。你拿着锤子找钉子是没有意义的。因为你不是真的懂了这个设计模式所能解决的问题。。。。换句话说。。你是坑掉少了。多掉几个设计上的坑。自然而然就用上了。
重构干嘛的？大多数情况是用来。没有设计思想的代码，改起来简直要了老命。重写。加入设计思想。完事

模式是总结出来的，从实践中来，到实践中去。

如果你的 “听说读写” 代码量没达到一个level 那就慢慢升级打怪吧。

从“过度设计”

看了设计模式之后才发现原来自己用过的方法有个名字。
但是还是记不住什么名字。

当你的程序足够复杂的时候，你就知道设计模式有什么好了。比如说MVC（准确的说MVC是几种设计模式的集合），我个人习惯写代码先从只有View写起，后来如觉得View太大，整合的逻辑太多，改起来费劲了，才把M和C拆出来。

我说的这个程序是我个人的兴趣项目，所以想怎么写就怎么写。如果是公司的项目，还是一开始就上MVC好。但是这也导致一个问题，初入公司的新程序员发现这样非常繁杂，有很多本来简单的事情搞得复杂，以及某些逻辑不知道写在哪个类合适，也不知道MVC有什么好处。