前言
中国人有不破不立的思维,远的如秦始皇焚书坑儒、项羽火烧阿房宫,近的如破“四旧”.正是由于有了这样的思想,于是,能改的就改,不能改的就推翻重写,没有一个持续开发蓝图。
破而后立
为什么要破才能立呢?为什么不能持续地发展?你说这是谁的错呢?是你架构师的错,你不能持续地拥抱变化,这是一个系统最失败的地方。那怎么才能实现拥抱变化的理想呢?设计模式!
设计模式是什么？
它是一套理论,由软件界的先辈们总结出的一套可以反复使用的经验,它可以提高代码的可重用性,增强系统的可维护性,以及解决一系列的复杂问题。
设计模式可以做什么？
做软件的人都知道需求是最难把握的,我们可以分析现有的需求,预测可能发生的变更,但是我们不能控制需求的变更。
问题来了,既然需求的变更是不可控的,那如何拥抱变化呢?幸运的是,设计模式给了我们指导,专家们首先提出了6大设计原则,但这6大设计原则仅仅是一系列“口号”,真正付诸实施还需要有详尽的指导方法,于是23种设计模式出现了。
设计模式不是工具
设计模式已经诞近20年了,设计模式不是工具,它是软件开发的哲学,它能指导你如何去设计个优秀的架构、编写一段健壮的代码、解决一个复杂的需求。
因为它是软件行业的经验总结,因此它具有更广泛的适应性,不管你使用什么编程语言,不管你遇到什么业务类型,设计模式都可以自由地“侵入”，因为它不是工具，所以它没有一个可以具体测量的标尺,完全以你自己的理解为准,你认为自己多了解它，你就有可能产生多少的优秀代码和设计。
因为它是指导思想，你可以在此基础上自由发挥，甚至是自己设计出一套设计模式。
设计模式VS框架
世界上最难的事有两件:一是让人心甘情愿地把钱掏出来给你,二是把自己的思想灌输到别人的脑子里。设计模式就属于第二种,它不是一种具体的技术,不像Struts, Spring, Hibemat等框架。一个工具用久了可以熟能生巧,就像砌墙的工人一样,长年累月地砌墙,他也知道如何把墙砌整齐,如何多快好省地干活,这是一个人的本能。
我们把Struts用得很溜，把Spring用得很顺手,这非常好,但这只是一个合格的程序员应该具备的基本能力!于是我们被冠以码农——软件行业的体力劳动者。
为什么要学设计模式？
如果你通晓了这23种设计模式就不同了,你可以站在一个更高的层次去赏析程序代码、软件设计、架构,完成从代码工人到架构师的蜕变。注意,我说的是“通晓”,别告诉我你把23种设计模式的含义、适应性、优缺点都搞清楚了就是通晓。错了!没有工作经验的积累是不可能真正理解设计模式的,这就像大家小时候一直不明白为什么爸爸妈妈要工作而不能每天陪自己玩一样。
内容摘自：《设计模式之禅》——秦小波
