潜泉

Singleton设计模式:保证一个类仅有一个实例,并提供一个访问它的全局访问点. 目的:Singleton是创建式设计模式,主要解决对象的创建问题.应保证类只有一个功能,即:创建自身的实例;因只有一个全局变化点,即:对象的创建.以下是单线程下的实例:public class Singleton{ public static Singleton instance=nu

<br />今天，稍微参悟了下 spring框架。<br />里面提到了 3种类、对象解耦的方式：<br />        接口注入；setter注入；构造注入；<br />前一种：比较倾向与纯面向对象的设计思想，主要通过接口来实现类、对象两两之间的耦合问题。<br />在真正实现方案时，比较偏向于应用设计模式来解决一切对象之间的问题，对反射应用不是很多。<br />后两种：比较倾向与通过文档和反射来解决一切耦合问题，当然也用到不少模式，但模式不会再是那种嵌套，将多个模式的变化点，放到一点的方式，更灵活的

<br />singleton模式有成单例模式，属于创建式模式。<br />类——对象一对一，一个类只能实现一个对象。<br />最简单的设计模式，也是最常见的设计模式，组件，模块初始化化必备的设计模式。<br />创建对象，往往和工程模式联合应用，初始化组件。<br />由于对象一对一方式出现，可以共享对象，实现多个用户访问一个对象，前提条件考虑对象锁，通常异步访问。<br />Java简单实例：<br />静态singleton方式：<br />public  static   StringBuffer

看了很久设计模式，学了很久，我开始坚信上帝的存在，我开始感觉到模式的无穷无尽，设计模式太难学了！那就难再，我们不是上帝，没法克隆一个和现实一样的流程，自动的代替人力，即使的在伟大的项目，也只是对现实社会一个片面的影子。设计很难，设计必须有针对性，在这里我在重新定位下我对设计模式的理解。看过金庸、古龙武侠的人，尤其是看过笑傲江湖的人，里面的独孤九剑，那就是BUG，无敌存在的。设计模式

Java开发人员做出的有关架构的最重要的决定之一便是如何使用Java异常模型。Java异常处理成为社区中讨论最多的话题之一。一些人认为Java语言中的已检查异常(Checked Exceptions)是一次失败的尝试。本文认为错误并不在于Java模型本身，而在于Java库设计人员没有认识到方法失败的两个基本原因。本文提倡思考异常情况的本质，并描述了有助于用户设计的设计模式。最后，本文讨论了异常处理

昨天，谷歌了几下，看看了现在的客服系统，蛮多的，总的说起了，样式五花八门；但要是论起辈分关系，老祖宗肯定是一个原理。大体的样式根据依赖可以分两类：依赖于操作系统本地应用软件，依赖于浏览器。前一种：QQ客服、MSN客服、淘宝客服等等，顺便多搜了几下，中国移动的飞信好像没有用这种实现的手段；后一种：可以是比较专业的客服，后台有自己专门的客服程序，前台也不依赖客户的操作系统，可以称作是一个独

我是一个初入设计的人，还是一个学生，从事过一段的时间的开发。从看过“设计模式”后，对设计模式产生了浓厚的兴趣，就像我去年看《数据结构》一样，一个就是一年的时间，很值！像是一个沙漠中的远行者，终于找的了一口井水。也许，他能说明程序员对编程的喜爱。给我带来了不少的想法，令我苦恼。想法：我在一个半医半计算机的学校上过，产生了一个这样的想法。（大家分享下，评论下）如果我们把人看作是一个软件

　　设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。　　毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。　　GoF的“设计模式”是第一次将设计模式提升到理论高度，并将之规范化，本书提出了23

面向对象就是更好的实现软件即插即用，一次编译出出运行，只增删新编译“数据结构”。不一定处处都用模式，有些过于细节的地方抽象起来，可以看成一个组建，将来需要更新的时侯直接更新组建（抽象集合）就行了。组建的创建及应用：也许要一个平衡，有了这个平衡，这个平衡的点我们可以看做是价值，平衡区间的取值我们可以看做价格，所以我们需要引入一个概念平衡区间，我们就需要求这个区间的值，等同于《概率论与数理统计》中

好久不去琢磨那些软件工程思想，从来也没想过要死板硬套，把有用的工具拿来，组合在一起，好用能真正做好事就够了。在做好事这个基础上，尽量的提炼有用的东西，去尝试的改进、改善工具和方法，争取做得更好。刚刚，搜了一下“面向对象编程、结构化编程”等词，大家还是对这种思想抱有