package Utils.Sort;

/**

*@author Linyco

*利用冒泡排序法对数组排序，数组中元素必须实现了Comparable接口。

*/

public class BubbleSort implements SortStrategy

{

  /**  *对数组obj中的元素以冒泡排序算法进行排序    */

       public void sort(Comparable[] obj)

       {     if (obj == null)

              {    throw new NullPointerException("The argument can not be null!");

              }

              Comparable tmp;

              for (int i = 0 ;i < obj.length ;i++ )

              {    //切记，每次都要从第一个开始比。最后的不用再比。

                     for (int j = 0 ;j < obj.length - i - 1 ;j++ )

                     {   //对邻接的元素进行比较，如果后面的小，就交换

                            if (obj[j].compareTo(obj[j + 1]) > 0)

                            {  tmp = obj[j];

                                   obj[j] = obj[j + 1];

                                   obj[j + 1] = tmp;

                            }   }

              }  }

}

经典的算法代码， 贴出来。

最简单的排序方法是冒泡排序方法。这种方法的基本思想是，将待排序的元素看作是竖着排列的“气泡”，较小的元素比较轻，从而要往上浮。在冒泡排序算法中我们要对这个“气泡”序列处理若干遍。所谓一遍处理，就是自底向上检查一遍这个序列，并时刻注意两个相邻的元素的顺序是否正确。如果发现两个相邻元素的顺序不对，即“轻”的元素在下面，就交换它们的位置。显然，处理一遍之后，“最轻”的元素就浮到了最高位置；处理二遍之后，“次轻”的元素就浮到了次高位置。在作第二遍处理时，由于最高位置上的元素已是“最轻”元素，所以不必检查。一般地，第i遍处理时，不必检查第i高位置以上的元素，因为经过前面i-1遍的处理，它们已正确地排好序。这个算法可实现如下。


Bubble Sort程序： 


STL C++程序：(VC++6.0通过)
#include "stdafx.h"
#include "iostream.h"

template<class T>
class doit{
private:
int x,y;
T temp;
public: 
doit(T* in,int count)
{
for(y=0;y<count-1;y++)
{
for(x=1;x<count-y;x++)
{
if((*(in+x))>(*(in+x-1)))
{
temp=(*(in+x-1));
(*(in+x-1))=(*(in+x));
(*(in+x))=temp;
}
}
}
}
};

int main()
{
double a[4]={1.1,1.3,1.9,2.2};
doit<double> d(a,4);
for(int i=0;i<4;i++)
{
cout<<a[i]<<endl;
}
return 0;
} 

C语言程序：(TC 2.0通过) 
void doit(float* in,int count)
{
int x;
int y;
float temp;
for(y=0;y<count-1;y++)
{
for(x=1;x<count-y;x++)
{
if((*(in+x))>(*(in+x-1)))
{
temp=(*(in+x-1));
(*(in+x-1))=(*(in+x));
(*(in+x))=temp;
}
}
}
}

     十一假期去参加了5天的crazy english集训营班，一群疯子在卖弄，在喉，在叫。

     总体感觉还不错，但我早已不会再想大学生那样激情荡漾，不会因为几句煽情的言语擦眼泪，疯狂的定义就是为一个目标的执着追求，就是为你的学业（事业）充满激情。的确，兴趣到热爱到为之疯狂，需要的是一种精神，支撑着你。

     学习归来，感触最深的是教师是一个非常重要的角色，“子不学，师之错”古人就这么说过了， 现在又何尝不是这样呢？ 老师需要激情，需要责任，需要耐心，需要关怀，去帮助每一个需要帮助的人，在学生的视野里，优秀的教师是伟大的，是能在学生的心里扎根的，他们会带着老师的教诲，激励去前进。 在这里我体会到了。

     集训营里重新学习了音标，发音，学会更加认真的做好一件小事的确可以纠正很多不良的影响。 坚持下去，每天坚持一句话，2008我们会相聚在北京。

     当然还有一些感觉不好的就是课程的费用也一直在疯狂突涨，对于那些尚未工作的学生来说仍然是一笔惊人的数目，有多少双期待的眼神又被迫打击了回来。

     最后的结业节目中有幸show了一下走秀步态，纯属现学现卖，不过总体还找到了一些感觉。

     也有幸进行了自己第一次的英语演讲，虽然自己在下面练习了很多次，但总有失利的时候，很遗憾， 不过我尽力了，为自己高兴。 实力的背后是艰苦的汗水，坚持，再坚持，不过你的步伐慢还是快，只要坚持就一定会到终点。

     待续...

敏捷开发
　　人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。
敏捷软件开发宣言：

• 个体和交互     胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作       胜过 合同谈判
• 响应变化       胜过 遵循计划

虽然右项也有价值，但是我们认为左项具有更大的价值。

• 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
• 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
• 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
• 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
• 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
• 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
• 工作的软件是首要的进度度量标准。
• 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
• 不断地关注优秀的技能和好的设计会增强敏捷能力。
• 简单是最根本的。
• 最好的构架、需求和设计出于自组织团队。
• 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

当软件开发需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。

• 僵化性： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
• 脆弱性： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
• 牢固性： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
• 粘滞性： 做正确的事情比做错误的事情要困难。
• 不必要的复杂性： 设计中包含有不具任何直接好处的基础结构。
• 不必要的重复性： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
• 晦涩性： 很难阅读、理解。没有很好地表现出意图。

敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：

• 单一职责原则(SRP)
  就一个类而言，应该仅有一个引起它变化的原因。
• 开放-封闭原则(OCP)
  软件实体应该是可以扩展的，但是不可修改。
• Liskov替换原则(LSP)
  子类型必须能够替换掉它们的基类型。
• 依赖倒置原则(DIP)
  抽象不应该依赖于细节。细节应该依赖于抽象。
• 接口隔离原则(ISP)
  不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
• 重用发布等价原则(REP)
  重用的粒度就是发布的粒度。
• 共同封闭原则(CCP)
  包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
• 共同重用原则(CRP)
  一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
• 无环依赖原则(ADP)
  在包的依赖关系图中不允许存在环。
• 稳定依赖原则(SDP)
  朝着稳定的方向进行依赖。
• 稳定抽象原则(SAP)
  包的抽象程度应该和其稳定程度一致。

　　上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，我们可以在更高层次的抽象上来理解设计，我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。

下面举一个简单的设计问题方面的模式与原则应用的示例：

问题：
　　选择设计运行在简易台灯中的软件，台灯由一个开关和一盏灯组成。你可以询问开关开着还是关着，也可以让灯打开或关闭。

解决方案一：
　　下面图1是一种最简单的解决方案，Switch对象可以轮询真实开关的状态，并且可以发送相应的turnOn和turnOff消息给Light。


解决方案二：
　　上面这个设计违反了两个设计原则：依赖倒置原则(DIP)和开放封闭原则(OCP)，DIP原则告诉我们要优先依赖于抽象类，而Switch依赖了具体类Light，对OCP的违反是在任何需要Switch的地方都要带上Light，这样就不能容易扩展Switch去管理除Light外的其他对象。为了解决这个方案，可以采用ABSTRACT SERVER模式，在Switch和Light之间引入一个接口，这样就使得Switch能够控制任何实现了这个接口的东西，这也就满足了DIP和OCP原则。如下面图2所示：



解决方案三：
　　上面图2所示解决方案，违返了单一职责原则(SRP)，它把Switch和Light绑定在一起，而它们可能会因为不同的原因而改变。这种问题可以采用ADAPTER模式来解决，适配器从Switchable 派生并委托给Light，问题就被优美的解决了，现在，Switch就可以控制任何能够被打开或者关闭的对象。但是这也需要会出时间和空间上的代价来换取。如下面图3所示：



　　敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。

参考文献

1. 设计模式-可复用面向对象软件的基础 -- 李英军等译
2. 重构-改善既有代码的设计 -- 侯捷等译
3. 敏捷软件开发-原则、模式与实现 -- 邓辉译

      极限编程（Extreme Programming，XP）是一门针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论，XP使开发者能够更有效的响应客户的需求变化，哪怕是在软件生命周期的后期。它强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接。

      XP实际上是一种经历过很多实践考验的一种软件开发的方法，它诞生了大概有5 年，它已经被成功的应用在许多大型的公司，如：Bayeris che Landesbank，Credit Swis s Life，DaimlerChrysler，First Union National Bank　Ford Motor Company and UBS.XP 的成功得益于它对客户满意度的特别强调，XP 是以开发符合客户需要的软件为目标而产生的一种方法论，XP 使开发者能够更有效的响应客户的需求变化，哪怕在软件生命周期的后期。

　　同时，XP 也很强调团队合作。团队包括：项目经理，客户，开发者。他们团结在一起来保证高质量的软件。XP 其实是一种保证成功的团队开发的简单而有效的方法。

　　XP 强调四种价值：交流，简易，回馈，勇气。XP 程序员之间紧密的相互交流，XP 程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项目一开始，XP 就强调通过对软件的不断测试来获得反馈，程序员尽可能早的把软件交给客户，并实现客户对软件需求提出的变化，有了这些基础，XP 程序员就可以自信的面对需求和软件技术的变化。

　　XP 是与众不同的，它有点象快步的舞蹈。XP 开发过程包括许多的小卡片，独立的看，这些小卡片没有什么意义，但是当它们组合在一起，一幅完整的美丽的图片就可以看见，XP方法有别于传统软件开发，它是软件开发的一种新的重要的发展。它改变了我们开发程序的传统思维方式。下面我们将介绍它带给我们那些改变。
 
　　XP属于轻量开发方法中较有影响的一种方法。轻量开发方法是相对于传统的重量开发方法而言。简单地理解，“量”的轻重是指用于软件过程管理和控制的、除程序量以外的“文档量”的多少。XP等轻量开发方法认识到，在当前很多情况下，按传统观念建立的大量文档，一方面需要消耗大量开发资源，同时却已失去帮助“预见、管理、决策和控制的依据”的作用。因此必须重新审视开发环节，去除臃肿累赘，轻装上阵。

一、XP的核心思想

      从长远看，早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务/系统细分为可以在较短周期解决的一个个子任务/模块，并且强调测试、代码质量和及早发现问题。通常，通过一个个短小的迭代周期，我们就可以获得一个个阶段性的进展，并且可以及时形成一个版本供用户参考，以便及时对用户可能的需求变更作出响应。

二、XP的十二种方法

      规划策略(The Planning Game)；
      结对编程(Pair programming)
      测试(Testing)
      重构(Refractoring)
      简单设计(Simple Design)
      代码集体所有权(Collective Code Ownership)
      持续集成(Continuous Integration)
      现场客户(On-site Customer)
      小型发布（Small Release）
      每周40小时工作制（40-hour Week）
      编码规范（Code Standards）
      系统隐喻（System Metaphor）

三、XP的四个核心价值

      极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage）。

　　XP用“沟通、简单、反馈和勇气”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

　　XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈和勇气”的态度来对待XP；轻松愉快地来感受XP的实践思想；自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值；有勇气接受它，或改进它。

四、XP 带给我们的变化

　　通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。这是真的吗？XP认为事实并非如此。

　　一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍，这意味着一个项目每年要花200 万美元在程序员身上，而仅仅花10 万美元在电脑设备上。很多聪明的程序员说：“我们如此聪明，发现一种方法可以节省20%的硬件开销”，然后他们使得源程序大而且难懂和难以维护，他们会说：“但是我们节省了20%或者2 万美元每年，很大的节省”。反之，如果我们写我们的程序简单而且容易扩展，我们将至少节省10%的人力开销，一笔更大的节省，这是你客户一定会注意到的一些事情。

　　另外一个对客户来说很重要的问题就是程序的BUGS 。XP 不只是强调测试，而且要求正确的测试。测试必须是能自动进行的，以便为程序和客户提供一个安全的环境。在编码的所有阶段，我们不断增加测试用例。当找到bug 时，我们就添加新的测试，一个紧密的安全网就这样产生了。同一个BUG 不出现两次，这些一定会引起用户的注意。你的客户必须注意的另外一件事情：XP 开发者拥抱需求变化。XP 使我们能够接受需求的变化。

　　一般情况下，客户只有在系统被开发完成以后能真正去体会它。XP 却不一样，它通过加强客户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。在XP 中，你的客户应该明确的知道这一点。

　　XP开发过程的大多的革命是在软件开发的方法上，代码质量的重要程度超出人们一般所认为的。仅仅因为我们的客户不能明白我们的源代码并不意味着我们可以不努力去管理代码的质量。

五、我们什么时候用XP

　　XP方法的产生是因为难以管理的需求变化，从一开始你的客户并不是很完全的知道他们要的系统是怎么样的，你可能面对的系统的功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变，这个时候应用XP 就可以取得别的方法不可能取得的成功。XP 方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内，需要一个相当难开发的系统，而且对于你的项目组来说，这个系统是一个新的挑战（从来没有做过），那风险就更大了，如果这个系统对于整个软件行业来说都是新的挑战，那么它的风险就更大了，采用XP 将可以减少风险，增加成功的可能。

　　XP方法是为小团体开发建立的，在2-10 个人之间。假如你的团体恰好合适，你就不需要用其他的软件工程方法了，就用XP ，但是要注意你不能将XP 方法应用于大团体的开发项目中。我们应该注意，在需求一惯呈动态变化或者高具有高风险的项目中，你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。

　　XP方法需要一个扩展的开发团体，XP 团体不仅仅包括开发者，经理、客户也是其中的一员，所有的工作一环扣一环，问问题，商讨方法和日程，增加功能测试，这些问题的解决不仅仅涉及到软件的开发者。

　　另一个需要是可测试性，你必须能增加自动的单元测试和功能测试，然而在你进行这个需求的时候，你会发现有许多的问题很难测试，这需要充分发挥你的测试的经验和智慧，而且你有时还要改变你的设计以便它可以更容易的进行测试。记住：那儿有需求，那儿就应该有测试的方法。

　　在XP方法的好处的清单上，最后一条是生产力。在同样的合作环境下，XP 项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP 方法学的真正目标。XP 真实追求的目标是：在规定的时间生产出满足客户需要的软件。假如对于你的开发来说，这是很重要的方面，你就可以选择XP 了。

六、极限编程的有效实践

1、完整团队

      XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

2、计划游戏

      计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

3、客户测试

      作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

4、简单设计

      团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

5、结对编程

      所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。

6、测试驱动开发

      编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

7、改进设计

      随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。

8、持续集成

      团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。

9、集体代码所有权

      任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。

10、编码标准

      系统中所有的代码看起来就好像是被单独一人编写的。

11、隐喻

      将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。

12、可持续的速度

      团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。