单一设计模式，顾名思义就是产生一个对象到单一实例，算是设计模式中最简单也是最容易理解的一种模式了。单一设计模式的设计很简，单目前主要有两种方法，要注意的是要把类到构造函数设为私有的，防止对象可以直接new一个实例出来，下面一种是很常见到一种。   public class SingletonPattern { private static SingletonPattern single = nu

背景 一个高效的软件开发过程对软件开发人员来说是至关重要的，决定着开发是痛苦的挣扎，还是不断进步的喜悦。国人对软件蓝领的不屑，对繁琐冗长的传统开发过程的不耐，使大多数开发人员无所适从。最近兴起的一些软件开发过程相关的技术，提供一些比较高效、实用的软件过程开发方法。其中比较基础、关键的一个技术就是测试驱动开发（Test-Driven Development）。虽然TDD光大于极限编程，但测试驱动开发

    Rational Rose的帮助文档上是这样定义“依赖”关系的：“依赖描述了两个模型元素之间的关系，如果被依赖的模型元素发生变化就会影响到另一个模型元素。典型的，在类图上，依赖关系表明客户类的操作会调用服务器类的操作。” 　　Martin Fowler在《Reducing Coupling》一文中这样描述耦合：“如果改变程序的一个模块要求另一个模块同时发生变化，就认为这两个模块发生了耦合。

  　 作为芸芸众程序员的一员，我对软件开发中的一切都充满问题。今天是关于测试，作为一名唯物主义者，我相信众物都有其神，于是我找到了测试之神。  　　  　　我问：神仙，为什么我们需要测试？  　　大神用怜悯的眼神看着我，说到：我可怜的孩子，之所以需要测试，都是上帝的错啊，上帝创造了你们，但是因为没有测试，所以你们都是不完美的、不理智的，你们会被情绪、环境左右，会犯错。  　　大神说这话的时候充满

    在面向对象的设计中，我们经常会听到或用到聚合、耦合的概念。面向对象的目标就是设计出高聚合、低耦合的程序。然而，究竟什么是聚合、什么是耦合，恐怕每个人都有自己的答案，换句话说，大多数人对聚合和耦合的概念是模糊的。小弟我今天就在此抛砖引玉，希望能给新入行的朋友和在校的学生一点帮助。声明一下，本文是我个人对聚合与耦合的理解，部分内容摘抄于互联网，不当之处还肯请各位高手指正。     因为聚合与耦

  工厂模式、控制反转及依赖注入      工厂模式原本作为高级篇的一个篇章（其难度充其量就那个难度），但是考虑与本章的联系，所以并入本章。      在介绍工厂模式与控制反转（Inversion of Control）及依赖注入（Dependency Injection）之前，先介绍下类的调用方法。目前调用方法总共有3种：1.自己创建；2.工厂模式；3.外部注入，其中外部注入即为控制反转/依赖注

转自：http://www.javaeye.com/topic/7776   1、接口的定义是由谁来定义的，但是这样的思路其实存在以下几个问题：    1)按照先定义接口，在进行实现的思路，那么肯定是先有interface，才有class的，对吧。那么咱们讨论一个真实的系统时：这就必然导致一个至顶向下的开发过程，那么我就需要问你了，当你用这样一种思路进行开发时，对于一个Web项目，你是不是会先从j

春节前的一篇那些炒作过度的技术和概念中对敏捷和中国ThoughtWorks的微辞引发了很多争议，也惊动了中国ThoughtWorks公司给我发来了邮件想来找我当面聊聊。对于Agile 的Fans们，意料之中地也对我进行了很多质疑和批评。我也回复了许多评论。不过，我的那些回复都是关于中国ThoughtWorks咨询师以及其咨询的方法的。我对Agile方法论中的具体内容评价的不是很多，所以，我想不妨讨

   依赖倒转原则解释：抽象不应该依赖于细节，细节应该依赖于抽象。说通俗点也就是针对接口编程，不要针对实现编程。      我们在做开发的时候，要访问数据库，就会把访问数据库的代码写成函数，每次去开发的时候调用这些函数就行了，其实这就叫高层模块依赖底层模块，违反了依赖倒转原则。      当我们做一个新项目的时候，发现业务逻辑的高层模块都是一样的，但是客户希望换成不同的数据库，这就出问题了，我们希

   依赖倒转原则解释：抽象不应该依赖于细节，细节应该依赖于抽象。说通俗点也就是针对接口编程，不要针对实现编程。    我们在做开发的时候，要访问数据库，就会把访问数据库的代码写成函数，每次去开发的时候调用这些函数就行了，其实这就叫高层模块依赖底层模块，违反了依赖倒转原则。    当我们做一个新项目的时候，发现业务逻辑的高层模块都是一样的，但是客户希望换成不同的数据库，这就出问题了，我们希望能再次

   单一职责原则解释：就一个类而言，应该只有一个引起它变化的原因。    我跟大家一样不喜欢看教条，教条太抽象不好理解，那我就举个生活中的例子便于大家理解我们知道现在的手机有拍照，打电话，彩信，摄像，听歌等等很多功能，我们出去旅游的时候其实只要带一个手机就好了，坐在车上无聊的时候可以听歌，打游戏，欣赏风景的时候可以拍照，碰到趣人趣事得时候还可以摄像，真是好啊。但是仔细想想，手机听歌有MP4或MP

   单一职责原则解释：就一个类而言，应该只有一个引起它变化的原因。      我跟大家一样不喜欢看教条，教条太抽象不好理解，那我就举个生活中的例子便于大家理解我们知道现在的手机有拍照，打电话，彩信，摄像，听歌等等很多功能，我们出去旅游的时候其实只要带一个手机就好了，坐在车上无聊的时候可以听歌，打游戏，欣赏风景的时候可以拍照，碰到趣人趣事得时候还可以摄像，真是好啊。但是仔细想想，手机听歌有MP4或

还记得以前和大家提到过的《各种流行的编程风格》吗？有一些人问我那些编程风格具体是什么样子的。下面是一个代码重构的实例，让我们看看那个流行的编程风格是实践是什么样的。下面的这个实践不是虚构，如有雷同，请对号入座。 首先，我们有一个表达式如下所示： 1 s = 7 ; 很明显，这个表达式的变量名太没意义了，很不利于程序的可读性，所以，我们需要取一个有意义的变量名： 1 slots = 7 ; 很好，不

http://coolshell.cn/articles/3980.html   里面这一条很棒： 我们的代码中有一个模块完美地工作了很多年了，只是代码太乱了。我说服了我的老板，我可以重写这个模块，于是我花了三个星期来重写这个模块。今天 ，我还记得，我的老板站在我的后面看着我，而我在在流着斗大的法汗珠去fix被我重写的“超级漂亮”的那个模块中一个接一个的bug。从那以后，我再也不重写代码了，除非有

Google为Android应用开发提供了eclipse加插件作为开发工具，基于eclipse可以方便调试apk，而对于底层开发人员 （比如opencore开发）没有提供类似直观的开发工具及调试手段。本文旨在介绍一种基于ddd+gdbserver的调试方法，用于类似 opencore的C层面的程序调试。   具体步骤如下： 开一个shell adb shell ps查看mediaserver进程号

1 引言 DDD，全名：Domain Driven Design，中文名：领域驱动设计。 2 DDD的分层 分层的架构方式是我们常用的，这里的分层是说n-layer，指的是逻辑的分层，目的是分离职责。常用的是三层：表现层，业务逻辑层，数据访问层。 DDD把原来经典三层（表现层，业务逻辑层，数据访问层）中的业务逻辑层又细分为两层：应用层和领域层。应用层负责领域对象的协调和调度，领域层包含具体的领域对

经常有网友问我端口聚合是指链路聚合还是VLAN trunking啊？为什么老师给他们讲的都是这个名称呢，是老师讲错了，还是书上有错。 我学网络这么久了，也一直实际使用中在把这两个词混用，其实这完全不是一回事。 我在百度上查了一下定义： 链路聚合是将两个或更多数据信道结合成一个单个的信道,该信道以一个单个的更高带宽的逻辑链路出现。链路聚合一般用来连接一个或多个带宽需求大的设备，例如连接骨干网络的服务

经常有网友问我端口聚合是指链路聚合还是VLAN trunking啊？为什么老师给他们讲的都是这个名称呢，是老师讲错了，还是书上有错。 我学网络这么久了，也一直实际使用中在把这两个词混用，其实这完全不是一回事。 我在百度上查了一下定义： 链路聚合是将两个或更多数据信道结合成一个单个的信道,该信道以一个单个的更高带宽的逻辑链路出现。链路聚合一般用来连接一个或多个带宽需求大的设备，例如连接骨干网络的服务

前言 此文译自CodeProject上<How I explained OOD to my wife >一文，该文章在Top Articles上排名第3，读了之后觉得非常好，就翻译出来，供不想读英文的同学参考学习。 作者(Shubho)的妻子(Farhana)打算重新做一名软件工程师(她本来是，后来因为他们孩子出生放弃了)，于是作者就试图根据自己在软件开发设计方面的经验帮助她学习面向对象设计(OO

最近买了本设计模式的书，名字叫《设计模式之禅》。这是我第一本设计模式的书，看了几章了感觉自己受益匪浅，所以想就把自己感觉到比较有意思的设计模式知识分享给大家。 首先说一下我们程序员为什么要学习设计模式把！下面是引用书上的原话： 你是程序员，没有问题，通过学习设计模式能够让你写出更加高效，优雅的代码； 你是架构师，那更好，设计模式可让你设计出健壮，稳定，高效的系统，并且自动地预防未来业务变化可能对系

原文出自 http://blog.csdn.net/Bitou_Von/archive/2009/05/23/4210654.aspx   架构师之路之 里氏代换原则（Liskov Substitution Principle, LSP） 1 什么是里氏代换原则     里氏代换原则是由麻省理工学院（MIT）计算机科学实验室的Liskov女士，在1987年的OOPSLA大会上发表的一篇文章《Dat

       六大设计原则之 单一职责原则         关于单一职责原则，我想大家都听过不少，今天来看看这个原则具体是什么，有哪些好处使我们需要选择遵守它呢？   一、定义 一个类只能因为一个原因而修改。 怎么理解呢？简单来说，一个类只能实现一项功能，或者换句话说，一个类只有一个职责，只有当这个职责发生变化，它才会被修改， 说白了就是一个类质感一个类该干的事。   二、好处 类的复杂性降低 可

1.    IoC与DI基本概念  "控制反转"本身是一个大而泛的概念，控制反转"普遍存在，比如事件处理模型、各种类型的接口回调等等，Martin Fowler根据"控制的哪一方面被反转了"这样的原则，把Spring为代表的框架所实现的"控制反转"称之为"依赖注入"。它们的共性是，均反转了"如何定位依赖的具体实现"。 依赖注入具体可以细分为三种形式：构造方法注入、设值注入、接口注入。 2.   

设计模式之依赖倒置原则 一、定义 高层模块不应该依赖底层模块，两者都应该依赖其抽象。抽象不应该以来细节。 简单理解，接口或者抽象不依赖于实现类，实现类依赖与接口或者抽象类。 二、好处 依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。 三、代码示例 比较简单的原则没必要 写些什么代码，看看上一个就好了的。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/gamecreating/archive/2010/03/22/5404589.aspx   关联，聚合，组合的区别及C++实现 收藏 类间关系 在类图中，除了需要描述单独的类的名称、属性和操作外，我们还需要描述类之间的联系，因为没有类是单独存在的，它们通常需要和别的类协作，创造比单独工作更大的语义。在UML类图中，关

 转自:http://www.cnblogs.com/GoodHelper/archive/2009/10/26/SpringNET_DI.html   今天看spring.net的文章 这文章的作者用三个很好的例子阐述了依赖注入的解耦性 第一个例子 普通的多态 第二个例子 运用工厂解除依赖耦合 第三个例子 刚是运用了依赖注入彻底解耦 这里它是用了spring.net  实际上一个简单的反射也行啦

 今天是5.25（我爱我） 对自己说： 亲爱的自己，从现在开始为了自己骄傲的活着，好好爱自己。 亲爱的自己，永远不要为难自己，过于苛求那是傻瓜干的事。 亲爱的自己，您有一万个理由要对别人好，没有一个理由要求别人对您好。 亲爱的自己，这个世界，只有回不去的，没有过不去的。 亲爱的自己，快乐、豁达、厚道必须做到，这样您就会幸福长寿。 自己，年年月月日日时时刻刻祝福自己：万事如意，身体健康！

如何向妻子解释OOD 前言 　　此文译自CodeProject上<How I explained OOD to my wife>一文，该文章在Top Articles上排名第3，读了之后觉得非常好，就翻译出来，供不想读英文的同学参考学习。 　　作者(Shubho)的妻子(Farhana)打算重新做一名软件工程师(她本来是，后来因为他们孩子出生放弃了)，于是作者就试图根据自己在软件开发设计方面的经验

dsdsd1dfdfdfsdfsfddfdfdfs

今天碰到一个题，问的是聚合和组合的区别，不是很清楚，到网上搜了一段话，摘录如下：   聚合：表示两个对象之间是整体和部分的弱关系，部分的生命周期可以超越整体。如电脑和鼠标。 组合：表示两个对象之间是整体和部分的强关系，部分的生命周期不能超越整体，或者说不能脱离整体而存在。组合关系的“部分”，是不能在整体之间进行共享的。 不过，如果你要说，眼睛可以移植，是不是说可以脱离人而存在，它们就不是组合关系了