1
incompatible 2014-08-07 16:29:14 +08:00 2
多读源码,无它
尤其是当你读到到一种模式被应用在数种不同场景时,会有一种豁然开朗的感觉 比如,当你弄明白了servlet filter的工作原理,再去看aopalliance的MethodInterceptor与MethodInvocation,会发现它们的设计如出一辙,心中大呼“卧槽!这就是chain of responsibility” 看的多了自然就会用了 |
2
DRcoding 2014-08-07 17:33:27 +08:00 1
想要实现某个功能结构或了解底层代码,看所谓的框架的源码的时候,发现原来我擦,它这里是用这种方法是这么处理的,虽然此时根本不知道这叫啥模式~~
遇到某个项目,要自己去架构的时候或者有棘手的问题的时候,在寻求解决方案的时候,突然想到以前看到的 “XXX模式”,“XXX方法” 好像是可以解决的~然后问题就被解决了。 |
3
sampeng 2014-08-07 17:38:22 +08:00 1
多看代码,写的每行代码都要思考。。所谓思考不是按照逻辑去考虑。是跳出来,站在最抽象的位置考虑。几年以后,设计模式就是个笑话了。。
设计模式只是个名词,核心是解决问题。你拿着锤子找钉子是没有意义的。因为你不是真的懂了这个设计模式所能解决的问题。。。。换句话说。。你是坑掉少了。多掉几个设计上的坑。自然而然就用上了。 重构干嘛的?大多数情况是用来。没有设计思想的代码,改起来简直要了老命。重写。加入设计思想。完事 |
4
plprapper 2014-08-07 18:29:05 +08:00
模式是总结出来的,从实践中来,到实践中去。
如果你的 “听说读写” 代码量没达到一个level 那就慢慢升级打怪吧。 |
5
novoland 2014-08-07 18:48:30 +08:00
从“过度设计”
|
6
c742435 2014-08-08 09:48:31 +08:00
看了设计模式之后才发现原来自己用过的方法有个名字。
但是还是记不住什么名字。 当你的程序足够复杂的时候,你就知道设计模式有什么好了。比如说MVC(准确的说MVC是几种设计模式的集合),我个人习惯写代码先从只有View写起,后来如果觉得View太大,整合的逻辑太多,改起来费劲了,才把M和C拆出来。 我说的这个程序是我个人的兴趣项目,所以想怎么写就怎么写。如果是公司的项目,还是一开始就上MVC好。但是这也导致一个问题,初入公司的新程序员发现这样非常繁杂,有很多本来简单的事情搞得复杂,以及某些逻辑不知道写在哪个类合适,也不知道MVC有什么好处。 |