该怎么解释？我懒得解释

导读：设计模式也在不知不觉中，学习完了。上回开会，知道自己现在所谓的学完了，真的只是很浅显的东西。不过，以后还会继续的研究学习，这才让我安心了点。编程是一门技术，更是一门艺术。路曼曼其修远兮，吾将上下而求索。一、基本概况概念：Design pattern，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。作用：可重用代码、让代码更容易被他人理解、保证代码可

导读：周日，又给徒弟验收项目了。以往常的习惯一样，每次验收，我都陪着徒弟一起总结学习过程中的问题，然后互相交流。这次，一个徒弟验收的是设计模式，一个徒弟验收的是UML，本篇博客，就先谢谢设计模式的东西。一、基本概念1.1，模式1.2，设计模式二、设计模式的来源三、模式与模型四、模式与框架五、框架和架构

导读：话说姑娘我一直想着分个总结设计模式来着，一直没把这个派上日程，现在看一本书，里面提到了一些设计模式，现在就总结总结。话说我之前写单例模式，一直都是按照大话设计模式上的那种写法，也就是传统的加锁，加2把锁的这种方式，今天看了看人家说性能优化，利用内部类，写出了更高逼格的代码，佩服之余，总结一番。一、两种常见写法分析1.1，单锁懒汉式public class Singleton

导读：话说，当年学习了大话设计模式，后来又学习了head first，脑袋里能画出UML图，能写出代码的，不多。以致于到前一段时间，我还不能背着写出很常用的单例模式的代码！但是，本宝宝从很久以前开始面试的时候，就敢往简历上写熟悉设计模式，比如：。。。。。。。。果然，我还是个宝宝！本篇博客主要是总结一下，我知识储备以外的关于代理模式的运用，主要是提升系统的反应效率！一、代理模式的设计意图

导读：上篇博客说到，我想将单例模式和代理模式结合起来，以尽可能避免在并发情况下的真实对象的重复创建。光说不练，假把式，代码走你！一、使用了单例模式的效果接口：public interface IDBQuery{ String Request();}实现类：DBQuery备注：添加构造方法，是为了测试本类被创建的次数public class DBQuery impleme

我，第一次用到外观模式，应该是3年多以前。那时候是做一个收费系统，在当时的U层和B层之间，加了一层Facade。当时，在一些复杂的业务逻辑处理时，感受到了加入外观层的好处，但对于一些简单的（我指的是，当时很多facade里面的方法都只是简单的返回了B层的方法执行结果）业务，总感觉是没有必要了。那么，外观模式，究竟可以发挥出多大的威力呢？？？？一、目前的框架后来，在项目的开发中，用到的设计模

前言：接触和使用设计模式都比较早，至少也是3年多以前的事儿。可惜，那时候初出茅庐，思想觉悟也不太高，上面说用什么，就用什么，缺乏了自己的思考。在这次的离职交接过程中，发现系统中有好些处都有设计模式的影子，遂决定，将设计模式重新总结一遍，并记录一些自己的思考！一、宏观导图总结二、本次思考的问题2.1，为什么设计模式被划分为三种类型2.2，为什么会是结构、创建、

在做excel模板解析的时候，其实会有两个部分，第一，将模板读取出来，校验一些必录项等。　但除了这些，在数据真正被业务线使用的时候，还会有一些其他的校验，比如说：根据业务，年龄是不能超过多少岁的，包括一些属性，在数据库、业务中是以什么类型传输应用的。　而且，这两个部分，都会面临着变化，模板并非一成不变，业务校验，也不可能一成不变。　怎样设计，才可以适应这种变化呢？　　　科普：变化驱动—