初观设计模式

    设计模式，是很多前辈的结晶。但是也不是一个模式就可以放任四海而用之。在学设计模式之时，个人认为，应该先记住每一个模式的定义。只有知道每一个模式的定义之后才能更好的理解它。

       在应用之时，才能更好的选择对应的模式来解决相关的方案。本人是一个C++程序员，就我目前所涉及的设计模式相关的书只有“四人帮”的那本设计模式采用了C++语言作为描语言，但是这本书基本都是概念，相当的枯燥。使人难于下咽。那是不是还有相关的书籍或者资料可以阅读或者查阅呢。果真有的，一次和同事之间聊天，他提到了《head first 设计模式》。

       在阅读此书的同时，我发现其是由java语言的来进行描述的。但是语言只是工具来说，用什么语言又有什么区别呢？同时还发现，在阅读设计模式相关的书籍的一个共同点，应该要有UML语言的基础。毕竟里面很多地方用到了类图。通过类图来对模式思想的描述。但是又不需要你是UML建模大神，只需要你知道箭头等各自代表的含义。言归正传，《head first 设计模式》这本书写的还是比较简单，其中有很多相关的例子，比如说对象村就很好给我建立面向对象的编程思想。

       作为C++程序员，刚开始的编程一般都是居于面向过程的编程思想，反正我是这样一步一步走过来的。写出的东西一般要求实现相关的功能，很少去考虑系统的复用，就算用到了复用也是将代码ctrl + c 和 ctrl + v，因此在做项目进度有时上不来并且错误率不低。相信这也是程序员的通病吧，一般都是一步一步走出来的。但是今天讲到了设计模式，那么也来说说设计模式对代码作用。这个可以举个例子来说，我们公司做项目一般都是哪里用到改哪里。本来好好的一个类或者说一个模块，该来该去估计连当初的作者都不认识了。问题也就随着出来了。当这个类出现bug的时候，就很难说是哪里出了bug，因为每一个程序员的水平都不一样，写出的代码也就是不一样了。那么如果发现当前的代码不符合我现在的功能了怎么办呢？我们是不是可以继承自这个类来实现我们的功能。然后对我们编写的类进行调试，也不会涉及到别人的类。那么现在问题又出现了，我们的类会越来越多，简直就是一个类爆炸。我们怎么去维护一个系统。我们可以用到了设计模式，更好的管理我们的代码。也能解决相关的问题。

       每个人都有各自不同的理解，出自不同的目的去学不同的东西。慢慢的接触了设计模式，逐步的写出自己对各个常用的模式的理解。