我们做的很多应用程序，很多功能都需要较长的加载时间，比如下载功能，转换页面等等。在程序进行后台处理的时候，前台的ui是没有反应的。如果在这段时间内我们不作任何处理就让程序停在那的话。第一，用户体验会很差。第二，如果用户在这段时间内不耐烦开始对界面猛点（我相信长时间程序没响应大家都会这么做），那么很可能使程序挂掉。所以我们需要在程序加载时弹出加载对话框，解决以上两个问题。

 

先给大家看一下效果图：

 

显示最新帖子界面：

 

 

点击最热按钮，跳转到显示最热帖子页面，在加载时弹出加载对话框：

 

 

加载完毕后，变成了最热页面：

 

这当中progressdialog是一个ProgressDialog的对象，show的参数依次为上下文，Dialog要显示的标题，Dialog显示的信息，第三个参数确定进度条是否为不确定，第四个确定是否可以被取消。至于你还想要设置它的其他属性，可以去查一下文档，里面有很多设置属性的函数，你可以通过这些函数把对话框改成你想要的样子。

 

然后我们要解决的一个问题就是如何在程序加载成功之后让对话框消失，显示新的页面内容。

 

代码如下：

 

 

首先定义一个Handler对象，重载其handlemessage方法，在这里面让ProgressDialog消失。

 

下面我以“最热”按钮为例，“最新”按钮和其基本一致。

 

  开始合作之后，装上了SVN，非常高效，我在VS写了一部分的代码，上传之后，别人通过下载或是更新，就更新到了合作同伴的VS里，相当于大家在一个VS里写代码。和保强他们聊天的时候，发现他们与SVN关联的文件是这个样子的

...

     摘要: SpringMVC框架介绍Spring框架提供了构造Web应用程序的全能MVC模块。Spring MVC分离了控制器、模型对象、分派器以及处理程序对象的角色，这种分离让它们更容易进行制定。是一个标准的MVC框架。那你猜一猜哪一部分应该是哪一部分？SpringMVC框架图                  &n...  阅读全文 工厂模式： 

一、引子 
              话说十年前，有一个用户，他家有三辆汽车——Benz奔驰、Bmw宝马、Audi奥迪，还雇了司机为他开车。不过，用户坐车时总是怪怪的：上 Benz车后跟司机说“开奔驰车！”， 
              坐上Bmw后他说“开宝马车！”，坐上Audi说“开奥迪车！”。你一定说：这人有病！直接说开车不就行了？！ 而当把这个用户的行为放到我们程序设计中来时，会发现这是一个 
              普遍存在的现象。幸运的是，这种有病的现象在OO（面向对象）语言中可以避免了。下面就以Java语言为基础来引入我们本文的主题：工厂模式。 

二、工厂模式分为： 

工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。 

1、简单工厂模式（Simple Factory） ：又称静态工厂方法模式，重命名上就可以看出这个模式一定很简单。它存在的目的很简单：定义一个用于创建对象的接口。 但不利于产生系列产品。 
在简单工厂模式中,一个工厂类处于对产品类实例化调用的中心位置上,它决定那一个产品类应当被实例化, 如同一个交通警察站在来往的车辆流中,决定放行那一个方向的车辆向那一个方向流动一样。 

Simple Factory 模式角色组成： 
1) 工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在java中它往往由一个具体类实现。 
         2) 抽象产品角色：它一般是具体产品继承的父类或者实现的接口。在java中由接口或者抽象类来实现。 
         3) 具体产品角色：工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。 
         
         下面我们从开闭原则（对扩展开放；对修改封闭）上来分析下简单工厂模式： 
         当用户增加了一辆车的时候，只要符合抽象产品制定的合同，那么只要通知工厂 类知道就可以被客户使用了。所以对产品部分来说，它是符合开闭原则的；但是工厂部分好像不太理想， 
         因为每增加一辆车，都要在工厂类中增加相应的业务逻辑或 者判断逻辑，这显然是违背开闭原则的。可想而知对于新产品的加入，工厂类是很被动的。对于这样的工厂类（在我们的例子 
         中是为CarFactory），我们称它为全能类或者上帝类。 
         我们举的例子是最简单的情况，而在实际应用中，很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品，所以这可能会把我们的上帝累坏了，也累 
         坏了我们这些程序员，于是工厂方法模式作为救世主出现了； 
        
        
        2、工厂方法模式（Factory Method）：又称为多形性工厂，工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模 
        式里不同的工厂子类来分担。工厂方法模式是简单工厂模式的进一步抽象化和推广，工厂方法模式里不再只由一个工厂类决定那一个产品类应当被实例化,这个决定被交给抽象工厂的子类去做。 
        
        Factory Method模式角色组成： 
        1)抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。 
     2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。 
       3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。 
       4)具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。 
       
       工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说，这样便分担了对象承受的压力；而且这样使得结构变得灵活 起来——当有新的产品（ 
       即用户的汽车）产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生成，那么就可以被客户使用，而不必去修改任何已有的代 码。可以看出工厂角色的结构也是符合开闭原则的！ 
       
       可以看出工厂方法的加入，使得对象的数量成倍增长。当产品种类非常多时，会出现大量的与之对应的工厂对象，这不是我们所希望的。因为如果不能避免这种情 况，可以考虑使用简单工厂 
       模式与工厂方法模式相结合的方式来减少工厂类：即对于产品树上类似的种类（一般是树的叶子中互为兄弟的）使用简单工厂模式来实现。 
       
       
       3、简单工厂模式与工厂方法模式小结： 
       
       工厂方法模式仿佛已经很完美的对对象的创建进行了包装，使得客户程序中仅仅处理抽象产品角色提供的接口。那我们是否一定要在代码中遍布工厂呢？大可不必。也许在下面情况下你可以 
       考虑使用工厂方法模式： 
     1)当客户程序不需要知道要使用对象的创建过程。 
     2)客户程序使用的对象存在变动的可能，或者根本就不知道使用哪一个具体的对象。 
简单工厂模式与工厂方法模式真正的避免了代码的改动了？没有。在简单工厂模式中，新产品的加入要修改工厂角色中的判断语句；而在工厂方法模式中，要么将判断逻辑留在抽象工厂角色 
中，要么在客户程序中将具体工厂角色写死（就象上面的例子一样）。而且产品对象创建条件的改变必然会引起工厂角色的修改。 面对这种情况，Java的反射机制与配置文件的巧妙结合突破 
了限制——这在Spring中完美的体现了出来。 

工厂方法模式和简单工厂模式在定义上的不同是很明显的。工厂方法模式的核心是一个抽象工厂类,而不像简单工厂模式, 把核心放在一个实类上。工厂方法模式可以允许很多实的工厂类从抽象 
工厂类继承下来, 从而可以在实际上成为多个简单工厂模式的综合,从而推广了简单工厂模式。反过来讲,简单工厂模式是由工厂方法模式退化而来。设想如果我们非常确定一个系统只需要一个实 
的工厂类, 那么就不妨把抽象工厂类合并到实的工厂类中去。而这样一来,我们就退化到简单工厂模式了。 

4、抽象工厂模式（Abstract Factory）：又称为工具箱，产生产品族，但不利于产生新的产品 

什么是产品族： 位于不同产品等级结构中，功能相关联的产品组成的家族。还是让我们用一个例子来形象地说明一下吧。回到抽象工厂模式的话题上。可以说，抽象工厂模式和工厂方法模式的 
区别就在于需要创建对象的复杂程度上。而且抽象工厂模式是三个里面最为抽象、最具一般性的。 抽象工厂模式的用意为：给客户端提供一个接口，可以创建多个产品族中的产品对象。 

使用抽象工厂模式还要满足一下条件： 
     1)系统中有多个产品族，而系统一次只可能消费其中一族产品。 
             2)同属于同一个产品族的产品以其使用。 
             
Abstract Factory模式角色组成（和工厂方法的如出一辙）： 
     1)抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。 
     2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。在java中它由具体的类来实现。 
     3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。 
     4)具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。  
     
     在抽象工厂模式中，抽象产品 (AbstractProduct) 可能是一个或多个，从而构成一个或多个产品族(Product Family)。 在只有一个产品族的情况下，抽象工厂模式实际上退化到工厂方法模式。 
     
三、总结 

三种模式从上到下逐步抽象，并且更具一般性。GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Method）与抽象工厂模式（Abstract Factory）。将简单工厂模式 
（Simple Factory）看为工厂方法模式的一种特例，两者归为一类。 

（1）简单工厂模式是由一个具体的类去创建其他类的实例，父类是相同的，父类是具体的。 
（2）工厂方法模式是有一个抽象的父类定义公共接口，子类负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成。 
（3）抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无须指定他们具体的类。它针对的是有多个产品的等级结构。而工厂方法模式针对的是一个产品的等级结构。 

四、个人总结 
总结之前，先说两个概念，请确保理解，如下： 
1. 产品：具体到某一实例，如：宝马，奔驰，J20，F35等； 
2. 产品族：具体到某一类产品，如：汽车（Car），飞机（Plane）等； 

简单工厂模式（Simple Factory）：适用于同一产品族，固定产品种类的情况，优点：代码简单，缺点：不利于增加新产品，需修改原有工厂代码； 
工厂方法模式（Factory Method）：适用于同一产品族，可变产品种类的情况，优点：代码简单，利于增加新产品，无需修改原有工厂代码，缺点：子工厂类遍布各处，子工厂类易泛滥； 
抽象工厂模式（Abstract Factory）：适用于不同产品族情况，优点：可生产不同产品族的产品，缺点：不利于增加新产品，即使在工厂类：ProductFactoryByFactory中，使用了调用产品 
  Factory创建对象，在增加新产品时，依然违背了不修改原有工厂代码的原则； 

五、延伸阅读 

Java的开闭原则：一个软件系统应该对开展时开放的，对修改时关闭的（Software entity should be open for extension, but closed for modification）；在设计一个模块的时候，应该 
可以使这个模块可以在不被修改的前提下被扩张。换言之，应该可以在不必修改源代码的情况下改变这个模块的行为。 

听上去很矛盾，但是通过一些使用一些设计模式就可以轻松的做到，如 适配器模式（adapter）等等。满足了OCP（Open-Closed Principle）原则可以给软件系统带来两个无法比拟的设计目标： 
  1.扩展性。通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求。 
  2.稳定性。已有的软件模块，特别是最重要的抽象层模块不能被修改，这就是变化中的软件系统有一定的稳定性和可延续性。 
3.维护性大大提高。 

怎么才能实现“开-闭”原则： 
抽象化是关键 
  解决问题的关键在于抽象化。在像java这样的面向对象的语言中，可以给系统定义出一个一劳永逸，不再更改的抽象设计，此设计允许有无穷无尽的实现，并且互不影响。在java语言中，给出一个 
  抽象的类或者接口，规定出具体方法必须提供的方法特征作为系统设计的抽象层。这个抽象层预见了所有的可能扩展，因此，在任何扩展情况下都不会改变。这就使得系统的抽象层不需要修改，从 
  而满足了“开-闭”原则的第二条：对修改是关闭的。 
  同时，由于从抽象层导出一个或多个新的具体类来实现抽象类或者接口就可以改变系统的行为，因此系统的设计对扩展时开放的，这就满足了“开-闭”原则的第一条：对可变性的封装原则 。如何 
  设计好抽象层的类或者接口，我们必须对系统的可变性进行封装。这就是所谓的”对可变性的封装原则"（Principle of Encapsulation of Variation short for EVP)对可变性的封装原则 讲的是找到 
  一个系统的可变因素，将其封装起来。 
“对可变性的封装原则”意味着两点： 
  1.一种可变性不应散落在很多角落，而应当被封装到一个对象里面。 
  2.一种可变性不应当与另一种可变性混合在一起。 

今天和同学聊天,她像我描述了她最近的情况  ,一个字形容那就是"累"     ---------身体累,心累，总之是各种累！！！

                                       

         她说：“生活真的不容易，当初真的不该放下学业而去选择打工赚钱，结果是赔了夫人又折兵。聊天的过程中她一直在后悔自己的选择，生活的无奈，让她变得苍老了许多。。。。。聊着聊着就谈到了我，我在那一直抱怨，很希望自己能快点赚钱。她发来了一个很无奈的表情说：”要有长远的思想，不要像我一样“；     和她相比，我现在是很幸运，能在自己喜欢的领域学习知识，至少将来不会像她那样了，但心里总还是有那个别不过来的弯。看着其他同学假期赚钱，我心里也痒痒呢，不过反过来想想，其实我收获的比他们更多，我这个假期赚的财富比他们多少N倍了。只是现在还体现不出来吧！！！

           有的时候很想给家里减轻点负担，赚点钱别自己的生活，但这似乎只能解决眼前的问题。从来没有为将来考虑过。从来没想过将来怎么办？现在暂时是赚到钱了，那以后呢，将来父母老了，我拿什么区孝敬父母？父母病了，需要大笔的医药费，去哪拿？这时候你在孝顺管用吗？没钱啥都白扯了！！！记得那次和米老师谈话，我就把我的这些想法说了出来，老师告诉我，这些困难都是暂时的，要想让家里人过好生活，那就得解决这种局面，眼前的小利益不能代表未来，那一刻我就告诉自己，我要改变这种态度，改变命运，作为学生我就要好好利用这个机会，用知识强大自己，虽然暂时打工能赚钱，我也要微微一笑略过！！！强大了以后会有大把大把的人民币或者是美元等着我呢。。。。。。。等父母老了，需要我的时候，我有能力去孝顺，而不是在那干掉眼泪，没办法。。。。。

          李嘉诚的演讲中曾说道：”打工才是最愚蠢的投资“；也许很多人会认为打工是在赚钱。其实打工才是最大最愚蠢的投资。人生最宝贵的是什么？除了我们的青春还有什么更宝贵？  我们大多数人都抱怨穷，抱怨没钱想做生意又找不到资金。其实想来多么的可笑！其实我们自己就是一座金山（无形资产），只是自己不敢承认自己的能力。宁可埋起来也不敢利用（是金子总是会发光的）。宁可委委屈屈地帮人打工，把自己的资产双手拱让给了你的老板。

　　我们试想一下，有谁生下来上天就会送给他一大堆金钱的？有几个是含着金汤勺出生的呢?有谁是准备非常齐全了完美了再去创业就成功了？含着金汤匙出生的人毕竟是极少数、富不过三代，许多伟业都是平凡人创造出来的。计划永远赶不上变化，特别是在如今这个信息高度快速传播的年代！其实我们要想想为什么自己一直是打工仔？那是因为你安于现状！因为你没有勇气，你天生胆小怕事不敢另择它路！因为你没有勇往直前，没有超越自我的精神！虽然你曾想过改变自己的生活、改变自己穷困的命运、但是我们没有做，因为我们不敢做！我们害怕输，我们害怕输的一穷再穷！最后连想都不敢想了，觉得自己就算努力了、拼搏了、抱着雄心大志、结果还没看到预想的成就，也就放弃了。到最后我们就只能是一个打工仔！

          天上永远不会掉馅饼,即使掉下来了,说不准会砸死你呢.生活的权利掌握在我们自己的手中,我们不要在走父母的老路了.从现在起不自卑,不退缩,敢作敢为,大胆前进,摆脱贫穷!!!做自己的老板

                   

                   人、活着就要有一身价值……

首先我们了解一个名词ORM，全称是（Object Relational Mapping），即对象关系映射。ORM的实现思想就是将关系数据库中表的数据映射成对象，以对象的形式展现，这样开发人员就可以把对数据库的操作转化为对这些对象的操作。Hibernate正是实现了这种思想，达到了方便开发人员以面向对象的思想来实现对数据库的操作。

Hibernate在实现ORM功能的时候主要用到的文件有：映射类（*.java）、映射文件（*.hbm.xml）和数据库配置文件（*.properties/*.cfg.xml），它们各自的作用如下。

映射类（*.java）：它是描述数据库表的结构，表中的字段在类中被描述成属性，将来就可以实现把表中的记录映射成为该类的对象了。

映射文件（*.hbm.xml）：它是指定数据库表和映射类之间的关系，包括映射类和数据库表的对应关系、表字段和类属性类型的对应关系以及表字段和类属性名称的对应关系等。

数据库配置文件（*.properties/*.cfg.xml）：它是指定与数据库连接时需要的连接信息，比如连接哪种数据库、登录数据库的用户名、登录密码以及连接字符串等。当然还可以把映射类的地址映射信息放在这里。

接下来让我们就一起走进Hibernate的七种映射关系：

1、单向一对一关联映射（one-to-one）：

两个对象之间一对的关系，例如：Person（人）-IdCard（身份证）

有两种策略可以实现一对一的关联映射：

*主键关联：即让两个对象具有相同的主键值，以表明它们之间的一一对应的关系；数据库表不会有额外的字段来维护它们之间的关系，仅通过表的主键来关联。如下图：

 

例子：单向一对一主键关联例子连接

*唯一外键关联：外键关联，本来是用于多对一的配置，但是加上唯一的限制之后（采用<many-to-one>标签来映射，指定多的一端unique为true，这样就限制了多的一端的多重性为一），也可以用来表示一对一关联关系，其实它就是多对一的特殊情况。如下图：

 

例子：单向一对一唯一外键关联例子连接

注意：因为一对一的主键关联映射扩展性不好，当我们的需要发生改变想要将其变为一对多的时候变无法操作了，所以我们遇到一对一关联的时候经常会采用唯一外键关联来解决问题，而很少使用一对一主键关联。

2、单向多对一关联映射（many-to-one）：

多对一关联映射原理：在多的一端加入一个外键，指向一的一端，如下图：

 

关键映射代码——在多的一端加入如下标签映射：

 

 

3、单向一对多关联映射（one-to-many）：

一对多关联映射和多对一关联映射原理是一致的，都是在多的一端加入一个外键，指向一的一端。如下图（学生和班级）：

 

注意：它与多对一的区别是维护的关系不同

*多对一维护的关系是：多指向一的关系，有了此关系，加载多的时候可以将一加载上来

*一对多维护的关系是：一指向多的关系，有了此关系，在加载一的时候可以将多加载上来

关键映射代码——在一的一端加入如下标签映射：

 

 

缺陷：因为多的一端Student不知道Classes的存在（也就是Student没有维护与Classes的关系）所以在保存Student的时候关系字段classesid是为null的，如果将该关系字段设置为非空，则将无法保存数据，常用解决办法是改用双向关联映射，参见6。

4、单向多对多映射（many-to-many）：

多对多关联映射新增加一张表才完成基本映射，如下图：

 

关键映射代码——可以在User的一端加入如下标签映射：

 

 

5、双向一对一关联映射：

对比单向一对一映射，需要在IdCard加入<one-to-one>标签，它不影响，只影响加载。如下图：

双向一对一主键映射关键映射代码——在IdCard端新加入如下标签映射：

 

 

双向一对一唯一外键映射关键映射代码——在IdCard端新加入如下标签映射：

 

 

注意：一对一唯一外键关联双向采用<one-to-one>标签映射，必须指定<one-to-one>标签中的property-ref属性为关系字段的名称

6、双向一对多关联映射（非常重要）：

采用一对多双向关联映射的目的主要是为了主要是为了解决一对多单向关联的缺陷而不是需求驱动的。

一对多双向关联的映射方式：

* 在一的一端的集合上采用<key>标签，在多的一端加入一个外键

* 在多的一端采用<many-to-one>标签

注意：<key>标签和<many-to-one>标签加入的字段保持一直，否则会产生数据混乱

关键映射代码：

在Classes的一端加入如下标签映射：

 

 

在Student的一端加入如下标签映射：

 

 

注释：inverse属性

* inverse属性可以用在一对多和多对多双向关联上，inverse属性默认为false，为false表示本端可以维护关系，如果inverse为true，则本端不能维护关系，会交给另一端维护关系，本端失效。所以一对多关联映射我们通常在多的一端维护关系，让一的一端失效。

* inverse是控制方向上的反转，只影响存储

7、双向多对多关联映射：

双向的目的就是为了两端都能将对方加载上来，和单向多对多的区别就是双向需要在两端都加入标签映射，需要注意的是：

* 生成的中间表名称必须一样

* 生成的中间表中的字段必须一样

Role（角色）端关键映射代码：

 

 

User（用户）端关键映射代码：

 

 

总结：对于上面这七种关联映射中，最重要的就是一对多的映射，因为它更贴近我们的现实生活，比如：教室和学生就可以是典型的一对多的关系，而我们开发软件的目的之一就是为了解决一些生活中重复性问题，把那些重复的问题交给计算机帮助我们完成，从而来提高我们的工作效率。一句话：生活离开不开编程，编程更离不开生活。