定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。 解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接

3.1 依赖倒置原则的定义      依赖倒置原则（Dependence Inversion Principle，简称DIP）这个名字看着有点别扭，“依赖”还“倒置”，这到底是什么意思？依赖倒置原则的原始定义是：High level modules should not depend upon low level modules. Both should depend upon abstracti

里氏代换原则（Liskov Substitution Principle, LSP） 1、里氏代换原则定义 若对于每一个类型S的对象o1，都存在一个类型T的对象o2，使得在所有针对T编写的程序P中，用o1替换o2后，程序P的行为功能不变，则S是T的子类型。 What is wanted here is something like the following substitution proper

  单一职责原则（Single Responsibility Principle），简称SRP。 定义： There should never be more than one reason for a class to change. 应该有且仅有一个原因引起类的变更。 有时候，开发人员设计接口的时候会有些问题，比如用户的属性和用户的行为被放在一个接口中声明。这就造成了业务对象和业务逻辑被放在了

 聚合函数         聚合函数对一组行中的某个列执行计算执行计算并返回单一的值。聚合函数忽略空值。聚合函数经常与 SELECT 语句的 GROUP BY 子句一同使用,所以有的时候也把其称之为分组函数。 分组函数的介绍 分组函数作用于一组数据，并对一组数据返回一个值. 常见的分组函数有：     函数名称       函数描述       Count       返回找到的记录数      

大话设计模式上的一个图，我用EA画出来的：                                             UML中的6大关系相关英文及音标： UML中的6大关系相关英文及音标：  依赖关系   dependency   [di'pendənsi]  关联关系   association    [ə,səuʃi'eiʃən]  聚合关系   aggregation    [

 设R(U)是一个属性集U上的 关系模式，X和Y是U的 子集。 　　若对于R(U)的任意两个可能的关系r1、r2，若r1[x]=r2[x],则r1[y]=r2[y]，或者若r1[x]不等于r2[x],则r1[y]不等于r2[y]，称X决定Y，或者Y依赖X。　 　　上面一段话是某些教材上的话，比较不好理解。简单点说就是：某个属性决定另一个属性时，称另一属性依赖于该属性。 比如在设计学生表时，一个学生

  struts2+spring2.5+hibernate+freemarker 所用到的最基本依赖包 列出来，方便以后查阅！ 其中还加入了上传，JSON-lib，jtds，log4j等组件，因为项目中基本都会用到，所以直接加进来了。 antlr-2.7.6.jar aopalliance.jar asm.jar aspectjweaver.jar cglib-2.1.3.jar commons-

  12.2  注解实现Bean依赖注入 12.2.1  概述        注解实现Bean配置主要用来进行如依赖注入、生命周期回调方法定义等，不能消除XML文件中的Bean元数据定义，且基于XML配置中的依赖注入的数据将覆盖基于注解配置中的依赖注入的数据。   Spring3的基于注解实现Bean依赖注入支持如下三种注解： Spring自带依赖注入注解： Spring自带的一套依赖注入注解；

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

我们知道FDD和TDD分别是频分双工和时分双工的英文缩写。FDD系统是指系统的发送和接收数据使用不同的频率，在上行和下行频率之间有双工间隔，如GSM、CDMA、WCDMA系统都是典型的FDD系统；时分双工系统则是系统的发送和接收使用相同的频段，上下行数据发送在时间上错开，通过在不同时隙发送上下行数据可有效避免上下行干扰，如TD-SCDMA就是TDD系统。那么，TDD和FDD之间有什么区别之处呢？

UML关系(泛化,实现,依赖,关联(聚合,组合)) UML的构造快包含3种：  (1) 事物（4种）：结构事物，行为事物，分组事物，注释事物 (2) 关系（4种）：泛化关系，实现关系，依赖关系，关联关系 (3) 图（10种）：用例图，类图，对象图，包图，组件图，部署图，状态图，活动图，序列图，协作图 事物是对模型中最具代表性的成分的抽象；关系把事物结合在一起；图聚集了相关的事物。     (2)

了了来了来了来了来了来了来了

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。 解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会

         肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。 定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。 解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类

单一职责原则，应该是在写代码中，不断遵循的一个定律。就一个类而言，应该仅有一个引起它变化的原因，这样，就可以减少耦合度，如果涉及的功能过多的话，会让这个类承担过多的职能，可复用性变差，维护起来也会很麻烦   原则嘛，就是原则。记住，牢记在心。代码才能更简洁，可维护~~！

定义：不要存在多于一个导致类变更的原因。 通俗的说，即一个类只负责一项职责。 问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。 解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不

肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。 定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。

定义： 高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。 解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与

1. 聚合： 是关联关系的一种特例，体现的是整体与部分拥有的关系，即 has-a 的关系，此时整体与部分之间可以分离。 //学校 class School { }; //学生 class Student { private: School* ps; }; 可以看到 Student 类中包含了一个 School 类的对象 指针，而且在创建一个Student 类对象时一定要对指针进行初始

1.单一职责原则，（Single Responsibility Principle）. 定义：There should never be more than one reason for a class to change，应该有且仅有一个原因引起类的变更。 职责：业务逻辑，或者对象能够承担的责任，并以某种行为方式来执行。 2.理解 该原则提出了对对象职责的一种理想期望。对象不应该承担太多职责，正

--案例01：简单测试 declare    type studenttabletype is table of varchar(10) index by binary_integer;    stu1  studenttabletype ; begin    stu1(1):='tom';    stu1(2):='wind';    dbms_output.put_line('第一个元素是：'

     在MVC架构中，整个系统被分离为许多单独的模块（仅仅对于根据用户请求得到合适的数据这一个功能来讲，至少存在M与C的分离），而MVC设计者的初衷之一就是实现各个模块间的松耦合，即相互间的关联性更小。      先举例如下：      在一个系统中，我们需要建立一个Email系统，实现Email的发送；      最简单的实现是直接创建一个EmailSender的模块，但是考虑到系统的扩展性

端口聚合也叫做以太通道（ethernet channel），主要用于 交换机之间连接。由于两个 交换机之间有多条冗余链路的时候，STP会将其中的几条链路关闭，只保留一条，这样可以避免二层的环路产生。但是，失去了路径冗余的优点，因为STP的链路切换会很慢，在50s左右。使用以太通道的话，交换机会把一组物理端口联合起来，做为一个逻辑的通道，也就是channel－group，这样交换机会认为这个逻辑通道

http://jianbo.de/b/archives/503 在交叉编译移植程序的时候，我们常常会遇到这样的情况：要编译的程序依赖于某个动态/静态链接库。而这个库也需要我们编译移植。在编译没有别的依赖的链接库的时候很简单，设置好交叉工具链、目标架构就可以了。而在编译有依赖需求的程序的时候，我们常常遇到找不到头文件、找不到库文件的问题。很是烦人。 要解决这个问题，其实还是很容易的。只需要先编译安装

原文链接：http://www.blogjava.net/lukangping/archive/2010/08/01/327693.html 红色部分为本文转载时添加的。 聚合：表示两个对象之间是整体和部分的弱关系，部分的生命周期可以超越整体。如电脑和鼠标，就可以用一下图形表示： 组合：表示两个对象之间是整体和部分的 强关系，部分的生命周期不能超越整体，或者说不能脱离整体而存在。组合关系的“部分”

项目上线，有时间总结一下当前的项目，对自己而言，一直是一个学习的过程。本篇总结我们的测试实践。本文分5部分，分别是：项目背景、系统架构与模块划分、我们的测试实践、自动化测试在项目中的价值与对自动化测试的进一步思考。 一、项目背景 所有对项目的介绍一定是从客户开始。 客户：我们的客户是一家全球领先的时尚内容提供商，通过遍布全球的员工，客户每天获取大量关于时装发布、产品设计、街边流行、城市热点等信息，

首先类之间的关系从宏观上可以分为：关联、依赖、继承，而其中关联又有两种特例：聚合和组合，不过在UML2.X中聚合和组合合成一种关系了。  从使用的频率来看，关联（包括聚合和组合）关系是使用最为广泛的；其次是依赖和继承 关联和依赖的区别： 从类之间关系的强弱程度来分，关联表示类之间的很强的关系；依赖表示类之间的较弱的关系； 从类之间关系的时间角度来分，关联表示类之间的“持久”关系，这种关系一般表示一

前言：常用RPM的朋友们都知道，RPM简单易用，但是它的依赖关系是最头疼的！有时候比方说A包需要B包，B包需要C包，C包需要A包，好了。这就是最常见的死锁了（类似数据库有木有？）。这个时候有以下几种方式可以解决：    A、强制安装 ----暴力型       使用rpm -i --force --nodeps  强制安装。忽略依赖关系。这种方法你可以先装A包，再装B包，再装C包。这样还是有点隐患