我对设计模式的理解

最近在看一本叫做《大话设计模式》的书，感觉本书的作者是下了功夫了，写的不错，通俗易懂而且表达很直接很明确，跟之前读过的几本书感觉不太一样，之前读的几本书作者弯弯绕绕，最后也不知道到底想说什么。
为了更好的巩固自己学到的东西，也为了是自己能坚持读完这本书，我决定把书中的设计模式按照自己的理解以文字+代码的方式展现，如有不对的地方还请多多指教。只有大家相互交流切磋，才能取得进步。
在介绍设计模式之前，我先先介绍一下自己的工作经历，也算是与大家分享一下自己家的职业道路吧。
我做软件也有三年了，一直用c/c++,之前工作过的都是一些比较大的公司，这些大公司基本上都有自己成熟的产品和软件架构，我的工作方式基本上就是头两三个月熟悉公司原有代码（另加一些杂七杂八的小活），这段时间基本上是最痛苦的那段时间，代码不熟悉，什么都做不了，为了解决一个简单的问题可能要花整整一天的时间来读相关的代码（读别人的代码真的很吃力），同样的问题老员工可能花上个1-2个小时就能轻松搞定，当时 深深的怀疑过自己的能力，感觉身边的“老员工”（所谓的老员工，其实就是来公司比我早，工作年限不见得比我长）都好牛X。
平安度过头两三个月之后，会进入到一个相对比较平静的时期，这时候代码比较熟悉了，解决问题也开始有点思路了，自我感觉还不错，对身边“老员工”狂热的崇拜之情也慢慢冷却下来。
这个时期的主要工作（也是在公司未来的主要工作）是在公司原有代码的基础上进行一些修修补补，只知道要实现某个功能只需要在原有代码的某个地方加上相应的代码就行，至于公司代码的设计模式只有三个字—-不知道，至于公司为什么要选用这种模式更是一无所知。其实这一时期是大多数程序员都会经历的瓶颈期，很多人会觉得活得很舒服，就像温水煮青蛙一样，这时候的水温是最合适最舒服的，很多程序员都是从这里开始停滞不前的。当然，并不是说这段时期就一定一无所获，随着工作时间的增长，还是会有所收获的，列如，本人就在此期间学会了用windebug和debugview等相关工具来排查问题。但相对于时间来说，这些收获确实有点得不偿失。
唠叨到此为止，开始今天的正题——设计模式。
没接触设计模式之前感觉没什么，三年的编码工作也安安稳稳的度过了，并没有觉得设计模式对我的工作有什么影响。一个偶然的机会我接触到了设计模式，感觉就好像打开了通往另一个世界的大门，自己的视野一下子开阔起来，这时候回看自己之前写的代码，简直像shi一样，顿时觉得无地自容。
那么什么是设计模式？说实话我也不知道，因为我也是刚刚接触，只了解一些皮毛，不敢妄自菲薄。只能说说现阶段自己现在对设计模式的理解。
我们都知道编程是为了解决问题。解决同一个问题，可能会有很多种的编码方式，你可以只写一个main函数，所有的功能代码都在这个main函数里，你也可以根据不同的功能编写不同的函数接口，然后在main函数里去调用相应的接口函数，当然，你也可以使用面向对象的编程方式，封装几个不同的类来实现。那么哪种方式是最好的呢？其实没有最好的。因为随着问题和需求的变化，之前采用的编码方式可能就不合适了。
设计模式会教给我们应该如何分析问题或需求，并在分析的基础上给出我们一个最优的编码方式。就好比十一黄金周，我们打算去香港游玩，但我们应该怎么去香港呢？高铁or飞机？这时候，会有一个叫”设计模式”的东西告诉你，十一期间是西太平洋的台风多发季，坐飞机的话受台风的影响会比较大，高铁虽然慢但时间也在你的接受范围内，所以最好是乘坐高铁，而且黄金周结束后可定会有一个返程高峰，最好把回来的高铁票也买上，以免耽误返程。
这篇文章虽然是写设计模式，但更多的内容是介绍自己的职业经历，其实跟设计模式没什么关系，下一篇我们就不写这么多废话了，直接从简单工厂模式和策略模式入手。