不做翻译需求的程序员 + 赠书
最近在做大量的代码 Review 的工作，尝试整理出一些大家在写代码时要避免的一些问题，同时也在读《代码整洁之道》和《代码里的世界观》。也在知识星球（同公众号名：Python程序员杂谈）中发了一些关于代码设计的内容。
python中的观察者模式
这是python高级编程中的一个例子，看了下，觉得很容易理解 ，和很容易使用，
重温设计模式之抽象工厂
上篇复习了工厂方法模式的使用，对于创建单个系列产品来说，工厂方法已经可以很好的满足“开-闭”原则，但是对于组合产品，由多系列组成的产品，就显得力不从心了。 工厂模式中工厂类得特点是职责单一，这也是工厂方法的优点，每个类不必要关联多种事务。但这种单一的特点也限制了工厂方法的扩展
重温设计模式之工厂方法
在前面重 《温设计模式之建造者模式（Builder）》一文中，从模板方法（Template Method）推演到建造者模式（Builder）的过程中我们发现从模板方法到建造者或者是工厂方法其实只有一步之距。 但归咎于两者的侧重点并不一样，模板方法更注重“定义算法骨架”然后是把算法的实现延迟到子类中，而工厂方法则是“定义创建对象的接口”，然后也是把要创建对象的实例化延迟到子类中。
闲扯设计模式
最近空余时间稍微多一点,每天吃完晚饭,出去溜达一圈,回来就写写总结，安排一下学习计划，还有时间随便扯点东西到博客上。话说最近看到关于“过劳死”的消息，深知生命应该有张有弛才行，且与大家共勉。 说到设计模式，我刚到公司的时候开始做一个遗留项目的二次开发，以及一个java web
设计模式的误区之一
今天继续看建造者模式，打算把昨天的文章最后的那个图给实现以下，使用反射和泛型，等所有代码快写完的时候发现实现起来远不如初始的Builder代码简洁。虽然灵活性是提升了，可以产生不同的产品了，但发现目的搞错了。我是用不同的Builder来产生不同的Product，看上篇文章最后的
重温设计模式之建造者模式（Builder）
这样的话有什么好处呢？其实好处很多，最总要的就是这是一种“<strong>打破</strong>”，打破了原先算法骨架的死板，这里的TemplateMethod可以更加灵活，可以通过子类来实现对不同ConcreteClass的依赖，从而可以达到在客户端通过不同的AnotherClass的子类（用多态和工厂很容易实现）灵活的完成操作，而不需要知晓藏在AnotherClass后面的AbstractClass。（我怎么觉得这里有些类似于工厂方法呢。。。这个以后再谈）
用Template Method来重构big Method
在《java与模式》一书中，关于模板方法的部分最后提到了使用模板方法来重构“大方法”。我个人感觉使用模板方法在重构某一个项目时来提高类的复用是比较可行的，如果说用它来打破“大方法”我觉得就不是那么直观了。其实关键问题在于这个大方法里面是不是有重复被用到的一段代码，这样重构之后才
重温设计模式之模板方法（Template Method）
先从模板方法模式开始说起吧，这个模式以前看的时候没有太注意，现在又看了一遍，发现这个模式了不得呀（路人甲：其实每个模式都了不得，嘿嘿）。就是想武侠剧中的飞叶伤人，普通人眼里树叶就是树叶，而在高手眼里，那就是“草木皆兵”。同样是简单的一个继承，人家GoF就能给你整成一个模式，还是个了不得的模式。难道这就是所谓的境界吗？
重温设计模式
设计模式是去年就专门花费大量时间学习过的内容了，见：设计模式。不过经典之所以为经典就是因为它可以经久不衰。就像是一坛陈酿，时间久了才能品出味儿来。设计模式就是一坛陈年佳酿，可谓是历久弥新。因此我们还是需要重温一下的，如果可以品到个中真味，那也可以算是收获丰盛了。
公告
《Django企业开发实战》已出版
豆瓣书评
图灵社区购买
京东购买
当当网购买
个人作品
《Django源码解析视频版》大纲-草稿《Backbone.js入门教程第二版》基于Django的网站系统: Typeidea