数位之墙的主题式汇整和机器自动聚合 Zhengyun_ustc 20070315 发现数位之墙竟然在半年前曾经这么说过，呵呵，很像我们最开始谈起的概念，只不过不再是搜索引擎人员来做“搜罗”，而是机器自动生成的，从而发现所有热点，并进一步精耕细作为一个一个有趣的话题，继而串连起来形成专题。百度新闻、Google新闻的原理也就是这样。只不过，新闻的自然语言处理还是相对简单的，毕竟文字规整，内容聚焦性

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

转：http://dreamhead.blogbus.com/logs/14189175.html 作为一个有理想、有追求的程序员，你成天被各种名词包围着，你对其中一个叫做敏捷的东西特别感兴趣，因为它特别强调人的作用，这听着都让做程序员的你感到舒服。为了让自己早日敏捷起来，你从众多的敏捷实践中选择了一个叫做测试驱动开发（Test Driven Development，TDD）的作为你的起始点。因为

依赖倒置原则， 例： BUTTON -》 LAMP 灯， 一个按钮控制灯的开关。 正常情况下我们都是BUTTON 直接调用LAMP  的开关方法， 这样存在着BUTTON 这个高层依赖于低层的LAMP ， 如果当按钮需要控制其它的设备时， 将无法重用。 并且这种高层依赖于低层的策略是存在着问题的。  那如何来解除这个依赖关系呢， 我们可以添加一个BUTTON 的BUTTONSERVERINTERF

   界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页

ddd 

fff 

实践测试驱动开发 版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明 http://dreamhead.blogbus.com/logs/14189175.html   作为一个有理想、有追求的程序员，你成天被各种名词包围着，你对其中一个叫做敏捷的东西特别感兴趣，因为它特别强调人的作用，这听着都让做程序员的你感到舒服。为了让自己早日敏捷起来，你从众多的敏捷实践中选择了一个叫做测试驱动

关联--依赖、组合--聚合   联系与区别： 依赖是比关联弱的关系，关联代表一种结构化的关系，体现在生成的代码中，以java为例：     若类A单向关联指向类B，则在类A中存在一个属性B   b。     若类A依赖类B，则不会有这个属性，类B的实例可能存在于某个方法调用的参数中，或某个方法的局部变量中。 例如代码：      依赖：----存在于某个方法调用的参数中，或某个方法的局部变量中。

这是一篇Msdn杂志的文章，具体可看这里 [url]http://msdn2.microsoft.com/zh-cn/magazine/cc337885.aspx[/url]，解释如何建造松散耦合的应用以及启用依赖注入。如果你项目中还没有启用依赖注入，建议好好看看，并且评估一下现在.net框架下的IoC容器，可阅读这篇Scott Hanselman的《 .NET依赖注入容器列表》。 自由、创新、研

这是一篇Msdn杂志的文章，具体可看这里http://msdn2.microsoft.com/zh-cn/magazine/cc337885.aspx，解释如何建造松散耦合的应用以及启用依赖注入。如果你项目中还没有启用依赖注入，建议好好看看，并且评估一下现在.net框架下的IoC容器，可阅读这篇Scott Hanselman的《.NET依赖注入容器列表》。

1.聚合关系也称"has-a"关系,组合关系也称"contains-a"关系 2.聚合关系表示事物的整体/部分关系的较弱情况,组合关系表示事物的整体/部分关系的较强的情况. 3.在聚合关系中,代表部分事物的可以属于多个聚合对象,可以为多个聚合对象共享,而且可以随时改变它所从属的聚合对象.代表部分事物的对象与代表聚合事物对象的生存期无关,一旦删除了它的一个聚合对象,不一定也就随即删除代表部分事物的对

问题描述： 有表tb，数据如下 A 1 A 2 A 3 A 4 A 5 1  2  5  3  4 2  2  3  4  5 0  3  4  2  5   如何输出 A 1 A 2 A 3 A 4 A 5 最大 最小  5以上个数 1  2  5  3  4   5    1       1 2  2  3  4  5   5    2       1 0  3  5  2  6   6   

问题描述： 有表tb，数据如下 A 1 A 2 A 3 A 4 A 5 1  2  5  3  4 2  2  3  4  5 0  3  4  2  5   如何输出 A 1 A 2 A 3 A 4 A 5 最大 最小  5以上个数 1  2  5  3  4   5    1       1 2  2  3  4  5   5    2       1 0  3  5  2  6   6   

原文：The Sellsian Approach 大约在1994年，Chris Sells向我解释了他是如何通过“其它程序员”来设计软件的。 “首先，如果我是其他程序员，我会写我想到的代码。然后我会做一些理所当然的事情让代码运行起来。” 我明白从事TDD（Test-Driven Development）的那些人也是用相似的方法，但是焦点在于，在反复开发和执行上，还有更多。并且他们还要确保测试，作为

                              “围城”式困境中的依赖注入模式及Spring（3）             依赖注入模式和工厂模式 由于依赖注入模式的功能之一是初始化一个类，所以可以通过依赖注入模式来获取对象。我们知道，这个功能一向是工厂模式的领地。于是，有很多人就公然宣称：依赖注入模式能够代替工厂模式。他们的理由之一是，既然有了IOC容器，就可以通过它来初始化对象。何

“围城”式困境中的依赖注入模式及Spring   写在前面的话 依赖注入模式、或者说IOC模式，随着Spring框架的崛起而被人老生常谈。但是，有一些人只是在使用Spring中被动的使用依赖注入模式。对于使用Spring和依赖注入模式给自己的项目带来了多少好处，我们没有仔细的计算过；我们使用Spring及依赖注入模式只是因为很多人都在这么使用，或者说轻量级容器现在很流行。 本文试图来谈谈依赖注入模

                                  和依赖的斗争                         ——谈谈使用模式前后的依赖关系变化     在面向对象的设计和编码过程中，类和类之间或多或少总有这样或那样的关系。除了继承和实现，其他的关系都可以归结到依赖这种关系里；所以说依赖是类之间最普遍的一种关系。而我们在设计和编码的时候，大部分时间都要和依赖打交道。可以说，一个

1.  关联：连接模型元素及链接实例，用一条实线来表示； 2.  依赖：表示一个元素以某种方式依赖于另一个元素，用一条虚线加箭头来表示； 3.  聚集：表示整体与部分的关系，用一条实线加空心菱形来表示； 4.  组成：表示整体与部分的有一关系，用一条实线加实心菱形来表示；              （关联，依赖，聚集，组成的异同见后描述） 5.  泛化（继承）：表示一般与特殊的关系，用一条实线加空

(以下转载自UMLCHINA论坛)     在UMLCHINA精华区,看到了一些关联和依赖的讨论,似乎越讲越糊涂.我想谈一点自己的看法:     1、在《UML参考手册》第37页中，指出“关联和泛化都是依赖关系，但是它们有更特别的语义，故它们有自己的名字和详细的语义。我们通常用依赖这个词来指其他的关系。”     2、在《UML参考手册》30页中，定义了关联为“关联描述了系统中对象或实例之间的离散

Spring 能有效地组织J2EE应用各层的对象。不管 是控制层的Action对象，还是业务层的Service对象，还是持久层的DAO对象，都可在Spring的 管理下有机地协调、运行。Spring将各层的对象以松耦合的方式组织在一起，Action对象无须关心Service对象的具体实现，Service对 象无须关心持久层对象的具体实现，各层对象的调用完全面向接口。当系统需要重构时，代码的改写量将

类之间的关系 <!--[if !supportLists]-->1． <!--[endif]-->种类： Generalization(泛化)，Dependency(依赖关系)、Association(关联关系)、Aggregation(聚合关系)、Composition(合成关系)。 <!--[if !supportLists]-->2．  <!--[endif]-->其中Aggregation

1.  关联：连接模型元素及链接实例，用一条实线来表示； 2.  依赖：表示一个元素以某种方式依赖于另一个元素，用一条虚线加箭头来表示； 3.  聚集：表示整体与部分的关系，用一条实线加空心菱形来表示； 4.  组成：表示整体与部分的有一关系，用一条实线加实心菱形来表示；              （关联，依赖，聚集，组成的异同见后描述） 5.  泛化（继承）：表示一般与特殊的关系，用一条实线加空

1.  关联：连接模型元素及链接实例，用一条实线来表示； 2.  依赖：表示一个元素以某种方式依赖于另一个元素，用一条虚线加箭头来表示； 3.  聚集：表示整体与部分的关系，用一条实线加空心菱形来表示； 4.  组成：表示整体与部分的有一关系，用一条实线加实心菱形来表示；              （关联，依赖，聚集，组成的异同见后描述） 5.  泛化（继承）：表示一般与特殊的关系，用一条实线加空

面向对象设计（Object-Oriented Design，OOD）方法是OO方法中一个中间过渡环节。其主要作用是对OOA分析的结果作进一步的规范化整理，以便能够被OOP直接接受。      面向对象设计（OOD）是一种软件设计方法，是一种工程化规范。这是毫无疑问的。按照Bjarne Stroustrup的说法，面向对象的编程范式（paradigm）是[Stroustrup, 97]：     

问题描述： 有表tb，数据如下 A 1 A 2 A 3 A 4 A 5 1  2  5  3  4 2  2  3  4  5 0  3  4  2  5   如何输出 A 1 A 2 A 3 A 4 A 5 最大 最小  5以上个数 1  2  5  3  4   5    1       1 2  2  3  4  5   5    2       1 0  3  5  2  6   6   

最近看了Eric Evans的DDD一书，有点感想，随便写一下。在DDD里一般把业务层分为应用服务处和领域模型层。应用服务是与具体的架构有关系的，而领域模型是独立与具体的架构的，是可以在不同的架构下移植的。就比如在EJB3.0中，我们的session bean，MDB等都可以做来实现应用服务层，而我们的业务核心可以放在领域模型层里，应用服务通过领域模型来实现具体的业务操作。        DDD中

你可以通过Holy Joe’s Blog直接访问，但是通常由于GFW的原因可能会上不去。所以无论是从效率和方便程度上来说用Google Reader都是是比较好的选择。 有关RSS的介绍可以参看什么是RSS? 另外，由于CSDN Blog日趋腐烂，所以我拿掉了不相关的链接、评论、订阅等等，尽量让Blog简洁。 通过以下方式订阅Holy Joe’s Blog：   Subscribe in a re

摘自《Java面向对象编程》一书，作者：孙卫琴 来源:www.javathinker.org 在建立对象模型时，很容易把依赖、关联和聚集关系混淆。当对象A和对象B之间存在依赖、关联或聚集关系时，对象A都有可能调用对象B的方法，这是三种关系之间的相同之处，除此之外，它们有着不同的特征。 1．依赖关系的特征 对于两个相对独立的系统，当一个系统负责构造另一个系统的实例，或者依赖另一个系统的服务时，这两个

Q: 为什么通过单元测试发现的 Bug 很少 ? A: 单元测试不是用来发现 Bug 的, 而是用来预防 Bug 的. 如果采用 TDD, 测试用例完成之时, 产品代码尚未编写, Bug更无从谈起.   Q: 那是否写单元测试就能提高代码质量了 ? A: 关于这一点, 似乎有人不这么看, <<TDD Opinion: Quality Is a Function of Thought and Ref