终于读完了《大话设计模式》，收到书的时间是2011-01-21，那时候，还在双安的数码大厦，现在公司已经搬到盘古大观了，转眼之间，已经一年的时间了。
趁着这段时间，工作比较清闲，两个星期的时间，看了接近一多半，也就是说从买到书有大段时间，是暂停状态。其实开篇计算器的例子，是给了我很大震动的，结合一年来的工作，终于算是一只脚迈进面向对象的大门了。
把代码设计好，是可以少加很多很多班的。
《倚天屠龙记》里，张无忌学太极拳，学了三遍以后，招数全忘了，那才是最高境界。
我觉得设计模式的学习，也是一个道理。没必要去生搬硬套，用概念，条框去卡，这个是什么模式，那个是什么模式。不记得名字没关系 ，甚至改经典模式的实现，都是可以的。你的目的是为了使代码更优美，更易维护呢，还是想让别人，让自己知道，自己用了模式？
学习设计模式，重要的是掌握几个原则：
1. 单一职责。每个类只实现一个功能，而不要融合太多功能在一个类里
2. 开放封闭原则。对增加开放，对修改关闭（增加功能可以，修。
3.依赖倒转原则。依赖于抽象（接口或父类），而不依赖于实现（子类）
4.迪米特法则（模块A只接触和自己有直接关系的模块B，如果模块B和模块C有直接关系， 而 模块A和模块C，没有，则A调用C ,要通过B,而不是直接调用）
以下的原则，是我在工作中总结的：
复制代码是危险的。如果有两段相同的代码，几乎可以说一定是有问题的，因为每次改动，要维护两段代码
尽量减少IO操作，如操作数据库，网络发送，甚至printf ，这些操作比直接操作内存，慢很多倍、
修改Bug时，一定要从最简单的基本的地方开始检查，不要检查到最底层没问题，发现是传入的某个参数是错的。先不要怀疑系统的部分。
设计架构，同时了解细节
有些Bug,调起来可能费时费力，甚至花个二三天，其实当时写的时候，只要稍微注意，就可以轻松避免。避免Bug的代价与找出并修改Bug的代价，实在是差太多了。
把一段长代码，分成很多小函数，便于维护，连自己都不愿看，不愿改的代码，百分百有问题。
写程序时，先把流程搞清楚。把各个流程用的函数写清楚，函数可以留空，这样编程就变成了填空题。
做新功能时，把数据结构的设计，放在较重要的位置