爱威尔

模板方法模式看上去好像是抽象与具体的关系，把具体实现交给子类便与扩展，这个设计模式好像是给我们一个处理流程，这个流程不变，在这个流程中有一个(或多个)业务是可变的，所以我们用抽象类固定这个流程架子，

虽然二十多种设计模式都是前辈总结出来的精华，但我觉得精华有点多了，这个状态模式我就看不懂，也不是说不理解，而是不知道为什么会是这样，也许是我太浮躁了或者是我的专注程度不够吧。

我们想分析一下我们要吧这个通用的代码生成工具做成什么样子的c/s 还是 b/s，如果要我决策我会选择b/s形式，这算是一个问题。 还有我们设计的实体是连接数据库还是不连接数据库，也就是说是先有数

说句实话设计模式这东西就像java编程设计的标准一样，还有java编程原则成为衡量java程序好坏和衡量java开发人员的标尺。 这些东西都不难理解，我们熟悉这些东西目的是为了可以在实际项目中用到

代理模式既可以控制资源的访问方式也可以作为拦截工具，在Java的框架中也有用到，hibernate的懒加载和spring的aop(面向方面编程) ，而java内置的代理也是通过Java的反射来实现的。

设计模式案例分析图，一个可以根据配置生成程序代码的设计模式综合案例

我们从字面可以先理解一下这个模式的适用范围，责任是什么，谁有责任，谁没责任，责任链意思就是说怎么把一个一个的责任串联起来。

我始终认为：越简单的行为内部蕴含着越复杂的逻辑。 就像爱因斯坦的相对论一样，一个简简单单的公式里面却蕴含着无穷的宇宙奥秘。 我们所讨论的命令模式就是这样的思维，还有我们现在火热的大数据和人工

这种模式单从技术层面来说，没有什么技术含量，这完全是生活的积累。 人都是有惰性的，这是真理。 比如你要买电脑，如果买笔记本那咱就不谈了(呵呵)，如果是买台式机，你要是买品牌机(好吧，当我没说)，

其实看着名字就能猜出一些端倪来，中介是干嘛的，你不会不知道，正如之前所说的，人对复杂的事情有天生的厌烦感。复杂就意味着交互多，那么把这些复杂的交互统一管理起来，而你只需要结果岂不美哉，这怎么是在说领