惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
V2EX
C
Check Point Blog
博客园_首页
B
Blog
D
Docker
U
Unit 42
量子位
I
InfoQ
有赞技术团队
有赞技术团队
Martin Fowler
Martin Fowler
GbyAI
GbyAI
L
LangChain Blog
云风的 BLOG
云风的 BLOG
博客园 - Franky
美团技术团队
T
The Blog of Author Tim Ferriss
阮一峰的网络日志
阮一峰的网络日志
月光博客
月光博客
Vercel News
Vercel News
Recent Announcements
Recent Announcements
雷峰网
雷峰网
大猫的无限游戏
大猫的无限游戏
小众软件
小众软件
Google DeepMind News
Google DeepMind News

博客园 - Franz

从如此简单的代码谈起 谈谈C#基元类型 TFS代码签入指导 并发之阿喀琉斯之踵 SmallDateTime时间范围检查 too many automatic redirections were attempted 预览Cube出现没有注册类错误 Transaction Manager Maximum Timeout .NET下的延迟加载 我的VisualStudio工具箱 简单的谈一下.NET下的AOP TFS上使用Beyond Compare来比较源码 SqlBulkCopy 是个好对象 释放Sql Server内存 吐槽一下Silverlight的SaveFileDialog. 定义加载动画 代码共享的小技巧 WPF将控件保存为图片 《编程人生》的书评
书评《模式-工程化实现及扩展》
Franz · 2012-06-24 · via 博客园 - Franz

书评《模式-工程化实现及扩展》

2012-06-24 21:09  Franz  阅读(189)  评论()    收藏  举报

设计模式,既然是模式自然也应被理解为套路。从使用方面来说,我们明白了场景,理解了套路所能应用的场景,我们做个一一对应也就容易了。
但是现实似乎不是这样的,似乎这里面充满了陷阱,很多情况是为了使用而使用,手里拿着锤子看所有的东西都是钉子。这难道是童年买新玩具新奇感的延续么,我想不是的。我们滥用不是因为我们想去用,而是不知道怎么是正确的用,我们大脑最开始的反应就是试错的思路去处理事情。我们期望经过多次试错找到一个合理的方式去使用此模式,但是这里的问题出现了从量的角度来说是不够的,一个项目的开发不足以涵盖所有模式(因为使用场景不是很多,而可怜的几个场景有能供你使用几个模式呢),我们试错的方式不是立刻显现出来,越到项目的后期越能体现原来设计的好坏。当然当你经历多个项目后,你慢慢的在试错中找到了感觉,也就用了经验,这也是为什么工作经验是重要的。
难道没有取巧之处么?  至少我认为是有更积极的方式去学习的。第一步,明细,明细要做到知道其是什么不是什么,它解决了你什么问题,它解决的这个问题带来了那些好处同时带来了那些弊端。尤其是弊端是你能接受的么(从数量上,工作的重复程度上去看)。
第二步,辨析,应用场景的辨析是要明细自己要完成的任务(你要解决的问题),正确的思路是:根据你要解决的问题,找解决问题的公式或者方法,逆向是走不通的。问题是从需求那里得出的(特别像从一道物理题中找出数学模型的过程),我们辨析问题,从中找到找到解决问题的步骤1,2,3. 在单个小问题中找出重复的问题提炼解决问题的办法(模式自然会被使用)。

第一步,看王翔的这书已经足够了。第二步要具体问题具体分析(在看一下分析方面的书)。