再谈对设计模式的理解

再谈对设计模式的理解

近期在公司，相对之前的工作环境，学习新的技术的时间少了很多。但是对所谓的旧知识却有了更深一步的理解。最近每每看 无论是大话还是headfirst 里面经典的改造方式都会心生惊喜。设计模式的原则和方法书中都 提到了很多。结合自己的感触谈几点。

原则

单一职责

一个庞大的系统来说，单一职责更方便开发和维护。对于类来说，一个类只做一件事。 对于方法来说，尽可能也单口入，单口出，只做一件事。力度合适，不至于冗余，也极大的提高了代码的复用程度。近期做的项目中，看到离职的人一个类5000行的代码，小编真的累觉不爱。同样，小编也看到过写的棒棒的代码。读起来赏心悦目。一看就知道这个类是用来做什么的，看到好多方法被引用的次数都有大几次。复用啊~
还有一个好处，是在这个项目中血的教训。面对需求的变更，各个功能糅合在一起，无论是新加需求还是简单的变更，总会“牵一发而动全身”。不是非常不利于开发，是简直不能开发。

依赖倒置

依赖抽象，不依赖细节。怎么样才能让自己的代码越写越轻松，怎么样才能让自己拥抱变化。找到共同点，并不断的去抽象和提炼去品味自己的代码。

思路

多闻”坏“了的味道

当我们实现某一个功能时，发现自己总写一样的代码。发现表面不一样，实际逻辑是一样的。发现一小部分代码总要不断的去重复。这时候，我们都可以抽象。抽象出一个方法，写一个接口，或是写一个抽象类， 一个虚方法。几处简单的变化，就能让我们的代码富有灵动性。

面向对象的思想

这总是一个循序渐进没有终点的过程。和面向对象比较起来，一个总是在想 这一步干什么， 下一步要干什么，最后一步要干什么。而面向对象要思考，这个类是用来干什么的，它能干什么。另一个类是用来干什么的，它又有什么那些本领。

体会

无论是哪一种设计模式，都是在基于继承，封装，多态不断的组合来解决特定的问题。通过近期的项目，感觉实用性很强。有一种”开发者心态“是总想着先完成功能吧，以后慢慢优化。实际上，坏的代码就是这样一点点积累的。当然可能考虑的不全面，的确需要功能实现以后再优化。但是，致力于做一个高级开发， 架构师 总要在动手之前，先动动脑子。
如果你的代码里一点抽象，都没有不管写的多完美无懈可击也顶多是一个优秀的实习生，而已。
设计模式的思想能给我们的代码插上翅膀~

总结

    代码体现着一个程序员的态度和品质。让代码铸就自己的品牌。