逛逛吧……

引子：[b]
每天都会逛论坛，但是每天都会逛完就撇，什么都没有留下，什么也不能拿走，哎！如今的时代都是快餐为主，就算你看到令你醍醐灌顶的绝顶好文，你也只是叫个好坐，之后就不了了之了。看过，激动过都是曾经的一刹那罢了，仔细思考，自己能不能每天看完一些好文后，都写一遍《逛逛论坛总结》呢，算是标识一下自己这一天看到了什么，对什么感兴趣，学到了什么。
[color=red]本人也做些说明吧：这些都是一些已发表的文章杜撰的，但是，本人可能无法一一列出出处，如果真的对你本人产生了影响，就电邮我把：daqing15@gmail.com[/color]。
[/b]

修炼我们程序员的内功：设计模式与面向对象思想！设计模式是对软件开发中普遍的一些问题一项重大方法结晶了，可是，作为一名程序员，真正能理解到这一精要的又有多少呢，大部分（包括自己吧）都是纸上谈兵与依样画葫芦。产生这的原因有很多，但是，可能都是因为工作中不怎么使用到设计模式；不能肯定自己在那种合适的场合何时合适地使用设计模式；开发经验少，还不足以真正的了解到设计模式之精华等等。但是，无论如何，前人给我们这些“小菜”们，总结了不少经验吧，我们总能吸取别人的经验。譬如
1、什么时候使用设计模式？
1.1 敏捷以及极限编程中倡导不预先设计,不会首次使用设计模式。但是如果符合设计模式的经典场合，那就不要居于小节了吧，直接上就是。
【敏捷、极限编程，哥们在这可要注意了，如果你对这两个词不怎么了解的，应该 GOOGLE或BAIDU吧，总没坏处的。万一某天，在面试的时候被问及这个，小哥你可就空有成足了吧！】
1.2 发现设计会引入坏味道、使用设计模式可以明显提高灵活性，也使用

2、过度设计的出现，如何防止
一个人总是想立马就实践自己学到的新技术，这种迫切的心情，大家都应该体会过。但是，如果过分的迷恋“设计模式”，也会给自己带来“过度设计”的问题。
2.1 继承结构层次太多造成过度复杂
2.2 继承与聚合不能分清楚 优先使用聚集而不是继承应该使用接口还是抽象类
继承本身没有错，关键主要是继承了不该继承的方法，很可能导致增加继承类的层次。采用了继承也不能像策略模式那样运行时变化行为。
2.3 过度抽象了你的接口。造成不必要的复杂性。
2.4 全局的公用类
通常都是在项目中复用了某些静态方法，而把其都集中在一个大类中。如此，貌似提高了复用，实际上项目中大多数包依赖于这种代码，造成不易拆解进行单元测试。不合符测试驱动的思想【驱动测试的概念？？？】，小心违反了借口隔离原则。

3、面向对象的设计原则
(1)单一职责原则
就一个类而言,应该仅有一个引起它变化的原因(否则就因该考虑这个类的职责分离)
(2)开闭原则
客户的需求是不稳定的，通过扩展已有的软件系统而不是通过修改软件系统来满足客户的需求，这样的软件系统就满足开－闭原则，即软件系统要有一定的灵活性和适应性。
已有的模块，特别是抽象层的模块不能修改，保证软件系统的稳定性和延续性。
[b]解决问题的关键是抽象化[/b]，把它与具体实现分离开来。接口（interface），抽象类的应用
[b]对可变性封装[/b]：将可变性封装到一个对象里。
(3)里氏替换原则
在有基类出现的地方，子类均可以替代。
当两个具体类关系违反里氏代换原则时，一种办法是抽象出一个基类，作为这两个类的父类，一种是应用组合聚合关系建立关系。
(4) 接口隔离原则
定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干
(5) 依赖倒转原则
抽象不应该依赖与细节，细节应当依赖与抽象。
要针对接口编程，而不是针对实现编程。
传递参数，或者在组合聚合关系中，尽量引用层次高的类
(6) 迪米特应法则
如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互关系.
如果其中一个类需要调用另外一个类的某一个方法的话,可以通过第三者转发这个调用