今天浏览一篇博客的时候看到的，觉得说的很有道理，一些疑点一下子就明了了！转载过来     留待日后巩固        在学习面向对象设计对象关系时，依赖、关联、聚合和组合这四种关系之间区别比较容易混淆。特别是后三种，仅仅是在语义上有所区别，所谓语义就是指上下文环境、特定情景等。他们在编程语言中的体现却是基本相同的，但是基本相同并不等于完全相同，这一点在我的前一篇博文《设计模式中类

         今天浏览一篇博客的时候看到的，觉得说的很有道理，一些疑点一下子就明了了！转载过来     留待日后巩固        在学习面向对象设计对象关系时，依赖、关联、聚合和组合这四种关系之间区别比较容易混淆。特别是后三种，仅仅是在语义上有所区别，所谓语义就是指上下文环境、特定情景等。他们在编程语言中的体现却是基本相同的，但是基本相同并不等于完全相同，这一点在我的前一篇博文《设计模式中类

             上篇文章提及到设计模式中应遵循的设计原则，并且列出了设计模式中应当遵循的六大原则。        次篇文章主要讨论单一职责原则。              单一职责原则(SRP)：                          不要存在多于一个导致类变更的原因。简单的讲，就是一个类或接口只负责一个"职责"。               如果一个类有一个以上的职责，这些

              在学习里氏替换原则之前，首先应该理解继承的概念与好处，我们知道在java程序设计语言      中继承是通过extends关键字实现的，那么继承到底有哪些优点呢？                  1、实现了代码共享                  2、提高了代码的重用性                  3、提高了代码的可扩展性              不过有利必

类之间的关系 1． 种类： Generalization(泛化)，Dependency(依赖关系)、Association(关联关系)、Aggregation(聚合关系)、Composition(合成关系)。 2．  其中Aggregation(聚合关系)、Composition(合成关系)属于Association(关联关系)，是特殊的Association关联关系。 3．  Generaliz

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 问题由来：类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 的子类型。

                依赖倒转原则，听名字感觉就十分的奇怪。“依赖”是什么？为什么要到转呢？理解这些         首先要从"依赖倒转原则"的定义入手。                 依赖倒转原则：                          高层模块不应该依赖于底层模块，而是应该依赖于抽象；抽象不应该依赖于具体的                  细节；细节应该依赖于抽象。

1、控制反转（IOC） IoC就是Inversion of Control，控制反转。在Java开发中，IoC意味着将你设计好的类交给系统去控制，而不是在你的类内部控制。这称为控制反转。 2、依赖注入（DI） DI就是Dependence Injection，依赖注入。 所谓依赖注入，即在运行期由容器将依赖关系注入到组件之中。 是在运行期，由Spring根据配置文件，将其他对象的引用通过组件的提供

这里给大家介绍一种在头文件中自动判断识别OpenCV的版本号，并据此添加对应的依赖库（.lib文件）的方法。具体代码如下： #ifndef _PREDEP_H_ #define _PREDEP_H_   #pragma once   #include "targetver.h"   #include <stdio.h> #include <tchar.h> #include <iostream>

  转自：http://www.yongfa365.com/Item/UML-Association-Dependency-Aggregation-Composition-Realization-Generalization.html  大话设计模式上的一个图，我用EA画出来的：   UML中的6大关系相关英文及音标：  依赖关系   dependency   [di'pendənsi]  关联关

转自：爱符号 http://www.afuhao.com/article_articleId-100_articleGroupId-42.shtml   近日需要实现一个导出功能，将数据导出到Excel中，由于以前写过，并且封装成一个类ExcelWriter，但是在调试的时候，出现一个奇怪的异常： 未在本地计算机上注册 Microsoft.Jet.OLEDB.4.0 提供程序 首先，我可以肯定代码

  转自： http://www.infoq.com/cn/news/2011/05/ci-dependency-management http://kb.cnblogs.com/page/101101/   在前文《分支策略(续)》中，我们讨论了多组件应用程序的持续集成策略，即：为相对独立的组件创建自己专属的代码库，然后通过现代持续集成工具进行组件间的持续集成。Joe的团队在首次发布之后，开始使

P07: 有依赖的背包问题 简化的问题 这种背包问题的物品间存在某种“依赖”的关系。也就是说，i依赖于j，表示若选物品i，则必须选物品j。为了简化起见，我们先设没有某个物品既依赖于别的物品，又被别的物品所依赖；另外，没有某件物品同时依赖多件物品。 算法 这个问题由NOIP2006金明的预算方案一题扩展而来。遵从该题的提法，将不依赖于别的物品的物品称为“主件”，依赖于某主件的物品称为“附件”。由这个

类与类图 1) 类(Class)封装了数据和行为，是面向对象的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称。 2) 在系统中，每个类具有一定的职责，职责指的是类所担任的任务，即类要完成什么样的功能，要承担什么样的义务。一个类可以有多种职责，设计得好的类一般只有一种职责，在定义类的时候，将类的职责分解成为类的属性和操作（即方法）。 3) 类的属性即类的数据职责，类的操作即类的行为职责

  UML定义的关系主要有六种：依赖、类属、关联、实现、聚合和组合。这些类间关系的理解和使用是掌握和应用UML的关键，而也就是这几种关系，往往会让初学者迷惑。这里给出这六种主要UML关系的说明和类图描述，一看之下，清晰明了；以下就分别介绍这几种关系： 继承【dependency】 指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与

这明显是上层依赖底层模块，底层可以复用，而上层不可复用，这就违反了里氏代换原则：一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件界面，把父类都替换成它的子类，程序的行为没有变化。 正是高层模块和底层模块都依赖抽象，所以才能满足底层和高层的低耦合，和无修改式的插入。面向接口编程！

随着WPF的推广，不得不重新拾起WPF来，因为这块的产品越来越多。 只能跟着MSDN来学了，所以想是在这里记录下学习的过程和对知识的理解。 先从最基本的吧，依赖项属性是WPF中不同的地方，先了解一下它吧。 “依赖项属性的用途在于提供一种方法来基于其他输入的值计算属性值”，这是官方的一句话，理解起来有点费劲。属性本身其实很简单，就是用来封装了字段的，本质上是两个访问器，来达到对字段值的读与写，以及从

类之间的关系 1． 种类： Generalization(泛化)，Dependency(依赖关系)、Association(关联关系)、Aggregation(聚合关系)、Composition(合成关系)。 2．  其中Aggregation(聚合关系)、Composition(合成关系)属于Association(关联关系)，是特殊的Association关联关系。 3．  Generaliz

简化的问题  这种背包问题的物品间存在某种“依赖”的关系。也就是说，i依赖于j，表示若选物品i，则必须选物品j。为了简化起见，我们先设没有某个物品既依赖于别的物品，又被别的物品所依赖；另外，没有某件物品同时依赖多件物品。  算法  这个问题由NOIP2006金明的预算方案一题扩展而来。遵从该题的提法，将不依赖于别的物品的物品称为“主件”，依赖于某主件的物品称为“附件”。由这个问题的简化条件可知所有

组合，聚合，关联，依赖 的区别 依赖与关联 依赖(Dependency ) : 含义:是类与类之间的连接,表示一个类依赖于另外一个类的定义;依赖关系仅仅描述了类与类之间的一种使用与被使用的关系; 体现:在Java和C++中体现为局部变量、方法/函数的参数或者是对静态方法的调用; 举例:人依赖于水和空气；汽车依赖汽油； UML图表示的依赖关系： 依赖： 比如说我要过河，没有桥怎么办，我就去借来一条小

  OOA 　　Object-Oriented Analysis：面向对象分析方法 　　是在一个系统的开发过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。OOA与结构化分析有较大的区别。OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。 　　OOA（面向对象的分析）模型由5个层次（主题层、对象类层、结构层、属性层和服

自己的思路是：参考了背包九讲，用01背包初始化每一组背包，然后用分组背包写，不过悲剧的超时了；于是参考别人的代码写了写，不过理解不是很好 #include <iostream> #include <cstring> #include <cstdio> using namespace std; #define max(a,b) a > b ? a : b #define clr(arr,val) m

今天学习robotlegs，碰到了依赖注入问题，作为一个没有写过java程序的ASer，对这些东西感到很深奥。于是搜索了下，百科这样解释道： 控制反转（Inversion of Control，英文缩写为IoC）是一个重要的面向对象编程的法则来削减计算机程序的耦合问题。 控制反转还有一个名字叫做依赖注入（Dependency Injection）。简称DI。 说白了，就是类A要使用类B，那么类A就

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

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

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 问题由来：类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 的子类

肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在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间接与类