MikeChen专注电子商务

一：使用场景

   1）使用的地方：树形结构，分支结构等

   2）使用的好处：降低客户端的使用，为了达到元件与组合件使用的一致性，增加了元件的编码

   3）使用后的坏处：代码不容易理解，需要你认真去研究，发现元件与组合件是怎么组合的

二：一个实际的例子

    画图形，这个模式，稍微要难理解一点，有了例子就说明了一切，我画的图是用接口做的，代码实现是抽象类为基类，你自己选择了，接口也可以。

1）先建立图形元件

   package com.mike.pattern.structure.composite;
/**
* 图形元件
* 
* @author taoyu
* 
* @since 2010-6-23
*/
public abstract class Graph {
/**图形名称*/
protected String name;

public Graph(String name){
   this.name=name;
}

/**画图*/
public abstract void draw()throws GraphException;

/**添加图形*/
public abstract void add(Graph graph)throws GraphException;

/**移掉图形*/
public abstract void remove(Graph graph)throws GraphException;

}

2)建立基础图形圆

package com.mike.pattern.structure.composite;
import static com.mike.util.Print.print;

/**
* 圆图形
* 
* @author taoyu
* 
* @since 2010-6-23
*/
public class Circle extends Graph {

public Circle(String name){
   super(name);
}

/**
* 圆添加图形
* @throws GraphException 
*/
@Override
public void add(Graph graph) throws GraphException {
   throw new GraphException("圆是基础图形，不能添加");
}

/**
* 圆画图
*/
@Override
public void draw()throws GraphException {
   print(name+"画好了");
}

/**
* 圆移掉图形
*/
@Override
public void remove(Graph graph)throws GraphException {
   throw new GraphException("圆是基础图形，不能移掉");
}

}

3）建立基础图形长方形

package com.mike.pattern.structure.composite;
import static com.mike.util.Print.print;
/**
* 长方形
* 
* @author taoyu
* 
* @since 2010-6-23
*/
public class Rectangle extends Graph {

public Rectangle(String name){
   super(name);
}

/**
* 长方形添加
*/
@Override
public void add(Graph graph) throws GraphException {
   throw new GraphException("长方形是基础图形，不能添加");
}

/**
* 画长方形
*/
@Override
public void draw() throws GraphException {
   print(name+"画好了");
}

@Override
public void remove(Graph graph) throws GraphException {
   throw new GraphException("长方形是基础图形，不能移掉");
}

}

4）最后简历组合图形

package com.mike.pattern.structure.composite;

import java.util.ArrayList;
import java.util.List;
import static com.mike.util.Print.print;

/**
* 图形组合体
* 
* @author taoyu
* 
* @since 2010-6-23
*/
public class Picture extends Graph {
private List<Graph> graphs;

public Picture(String name){
   super(name);
   /**默认是10个长度*/
   graphs=new ArrayList<Graph>();
}


/**
* 添加图形元件
*/
@Override
public void add(Graph graph) throws GraphException {
   graphs.add(graph);
}

/**
* 图形元件画图
*/
@Override
public void draw() throws GraphException {
   print("图形容器："+name+" 开始创建");
   for(Graph g : graphs){
    g.draw();
   }
}

/**
* 图形元件移掉图形元件
*/
@Override
public void remove(Graph graph) throws GraphException {
   graphs.remove(graph);
}

}

5）最后测试

public static void main(String[] args)throws GraphException {
   /**画一个圆，圆里包含一个圆和长方形*/
   Picture picture=new Picture("立方体圆");
   picture.add(new Circle("圆"));
   picture.add(new Rectangle("长方形"));
  
   Picture root=new Picture("怪物图形"); 
   root.add(new Circle("圆"));
   root.add(picture);
   root.draw();
}

6)使用心得：的确降低了客户端的使用情况，让整个图形可控了，当是你要深入去理解，才真名明白采用该模式的含义，不太容易理解。

一：使用场景

     1）使用的地方：我想使用两个不同类的方法，这个时候你需要把它们组合起来使用

     2）目前使用的情况：我会把两个类用户组合的方式放到一起，编程思想think in java里已经提到个，能尽量用组合就用组合，继承一般考虑再后。

     3）使用后的好处：你不需要改动以前的代码，只是新封装了一新类，由这个类来提供两个类的方法，这个时候：一定会想到facade外观模式，本来是多个类使用的情况，我新封装成一个类来使用，而这个类我采用组合的方式来包装新的方法。我的理解是，设计模式本身就是为了帮助解决特定的业务场景而故意把模式划分对应的模式类别，其实大多数情况，都解决了同样的问题，这个时候其实没有必要过多的纠缠到模式的名字上了，你有好的注意，你甚至取一个新的名字来概括这样的使用场景。

    4）使用的坏处：适配器模式，有两种方式来实现。一个是组合一个是继承，我觉得，首先应该考虑组合，能用组合就不要用继承，这是第一个。第二个，你采用继承来实现，那肯定会加大继承树结构，如果你的继承关系本身就很复杂了，这肯定会加大继承关系的维护，不有利于代码的理解，或则更加繁琐。继承是为了解决重用的为题而出现的，所以我觉得不应该滥用继承，有机会可以考虑同样别的方案。

二：一个实际的例子

      关联营销的例子，用户购买完商品后，我又推荐他相关别的商品

      由于减少代码，方法我都不采用接口，直接由类来提供，代码只是一个范例而已，都精简了。

1)创建订单信息

public class Order {
private Long orderId;
private String nickName;

public Order(Long orderId,String nickName){
   this.orderId=orderId;
   this.nickName=nickName;
}

/**
* 用户下订单
*/
public void insertOrder(){
  
}
}

2）商品信息

public class Auction {
/**商品名称*/
private String name;

/**制造商*/
private String company;

/**制造日期*/
private Date date;


public Auction(String name,String company, Date date){
   this.name=name;
   this.company=company;
   this.date=date;
}

/**
* 推广的商品列表
*/
public void commendAuction(){
  
}

}

3）购物

public class Trade {
/**用户订单*/
private Order order;

/**商品信息*/
private Auction auction;

public Trade(Order order ,Auction auction){
   this.order=order;
   this.auction=auction;
}

/**
* 用户产生订单以及后续的事情
*/
public void trade(){
   /**下订单*/
   order.insertOrder();
  
   /**关联推荐相关的商品*/
   auction.commendAuction();
}

}

   4）使用心得：其实外面采用了很多继承的方式，order继承auction之后，利用super .inserOrder()再加一个auction.recommendAuction(),实际上大同小异，我到觉得采用组合更容易理解以及代码更加优美点。

一：使用场景

   1)使用到的地方：如果你想创建类似汽车这样的对象，首先要创建轮子，玻璃，桌椅，发动机，外廓等，这些部件都创建好后，最后创建汽车成品，部件的创建和汽车的组装过程本身都很复杂的情况，希望把部件的创建和成品的组装分开来做，这样把要做的事情分割开来，降低对象实现的复杂度，也降低以后成本的维护，把汽车的部件创建和组装过程独立出两个对应的工厂来做，有点类似建立两个对应的部件创建工厂和汽车组装工厂两个工厂，而工厂只是创建一个成品，并没有把里面的步骤也独立出来，应该说Builder模式比工厂模式又进了一步。

    2）采用Builder模式后的好处：把一个负责的对象的创建过程分解，把一个对象的创建分成两个对象来负责创建，代码更有利于维护，可扩性比较好。

   3）采用Builder模式后的坏处：实现起来，对应的接口以及部件的对象的创建比较多，代码相对来讲，比较多了，估计刚开始你会有点晕，这个可以考虑代码精简的问题，增加代码的可读性。  

二：一个实际的例子

汽车的组装

  1)首先创建汽车这个成品对象，包含什么的成员

public class Car implements Serializable{

/**
* 汽车序列号
*/
private static final long serialVersionUID = 1L;

/**汽车轮子*/
private Wheel wheel;

/**汽车发动机*/
private Engine engine;

/**汽车玻璃*/
private Glass glass;

/**汽车座椅*/
private Chair chair;

public Wheel getWheel() {
   return wheel;
}

public void setWheel(Wheel wheel) {
   this.wheel = wheel;
}

public Engine getEngine() {
   return engine;
}

public void setEngine(Engine engine) {
   this.engine = engine;
}

public Glass getGlass() {
   return glass;
}

public void setGlass(Glass glass) {
   this.glass = glass;
}

public Chair getChair() {
   return chair;
}

public void setChair(Chair chair) {
   this.chair = chair;
}

}

2）创建对应汽车零部件

public class Wheel {
public Wheel(){
   print("--汽车轮子构建完毕--");
}
}

public class Engine {
public Engine(){
   print("--汽车发动机构建完毕--");
}
}

public class Glass {
public Glass(){
   print("--汽车玻璃构建完毕--");
}
}

public class Chair {
public Chair(){
   print("--汽车座椅构建完毕--");
}
}

3）开始重点了，汽车成品的组装过程

   public interface Builder {
/**组装汽车轮子*/
public void buildWheel();

/**组装汽车发动机*/
public void buildEngine();

/**组装汽车玻璃*/
public void buildGlass();

/**组装汽车座椅*/
public void buildChair();

/**返回组装好的汽车*/
public Car getCar();
}

以及实现类

public class CarBuilder implements Builder {
/**汽车成品*/
private Car car;

public CarBuilder(){
   car=new Car();
}

/**组装汽车轮子*/
@Override
public void buildChair() {
   car.setChair(new Chair());
}

/**组装汽车发动机*/
@Override
public void buildEngine() {
   car.setEngine(new Engine());
}

/**组装汽车玻璃*/
@Override
public void buildGlass() {
   car.setGlass(new Glass());
}

/**组装汽车座椅*/
@Override
public void buildWheel() {
   car.setWheel(new Wheel());
}

/**返回组装好的汽车*/
@Override
public Car getCar() {
   buildChair();
   buildEngine();
   buildGlass();
   buildWheel();
   print("--整个汽车构建完毕--");
   return car;
}

}

4）最后汽车创建测试

   public static void main(String[] args) {
   /**创建汽车组装*/
   Builder carBuilder=new CarBuilder();
   Car car=carBuilder.getCar();
}

   最后输出：

--汽车座椅构建完毕--
--汽车发动机构建完毕--
--汽车玻璃构建完毕--
--汽车轮子构建完毕--
--整个汽车构建完毕--

   5）体会心得：Builder模式实际的重点就把汽车的组装过程和零部件的生产分开来实现，零部件的生成主要靠自己的对象来实现，我上面只是在构造函数里创建了，比较简单，而重点汽车的组装则交给CarBuilder来实现，最终由builder来先负责零部件的创建，最后返回出成品的汽车。

一：使用场景

    1）经常使用的地方：一个类只有一个实例，eg:页面访问统计pv，统计的个数就只能保证一个实例的统计。

    2）我们目前使用的情况：比如我想创建一个对象，这个对象希望只有一份实例的维护，在内存的保存也只有一份，也就是在同一个jvm的java堆里只保存一份实例对象，所以你会想一办法，在创建这个对象的时候，就已经能保证只有一份。

    3）怎么改进：定义该对象的时候，就保证是同一份实例，比如：定义为私有构造函数，防止通过new的方式可以创建对象，然后在对象里定义一个静态的私有成员（本身对象的一个实例），然后再创建一个外面访问该对象的方法就好了。

    4）改进的好处：代码在编译代码这个级别就被控制了，不至于在jvm里运行的时候才来保证，把唯一实例的创建保证在编译阶段；jvm里内存只有一份，从而内存占有率更低，以及更方便java垃圾回收

    5）改进后的坏处：只能是代码稍微需要更多点，其实大家最后发现改进后的坏处，都是代码定义比之间要多一点，但以后的维护代码就降下来了，也短暂的代码量偏大来换取以后代码的精简。

二：一个实际的例子

总体的例子

package com.mike.pattern.singleton;

/**
* 总统
* 
* @author taoyu
* 
* @since 2010-6-22
*/
public class President {
private President(){
   System.out.println("总统已经选举出来了");
}

/**总统只有一个*/
private static President president=new President();

/**
* 返回总统
*/
public static President getPresident(){
   return president;
}

/**
* 总统宣布选举成功
*/
public void announce(){
   System.out.println("伟大的中国人民，我将成你们新的总统");
}
}

/**
* @param args
*/
public static void main(String[] args) {
   President president=President.getPresident();
   president.announce();
}

1.使用场景

     1）子类过多，不容易管理；构造对象过程过长；精简代码创建；

    2)目前我们代码情况： 编写代码的时候，我们经常都在new对象，创建一个个的对象，而且还有很多麻烦的创建方式，eg:HashMap<String,Float> grade=new HashMap<String,Float>(),这样的代码创建方式太冗长了，难道你没有想过把这个创建变的短一点么，比如：HashMap<String,Float>grade=HashMapFactory.new(),可以把你创建精简一点；你也可以还有别的需求，在创建对象的时候，你需要不同的情况，创建统一种类别的对象，eg:我想生成不同的汽车，创建小轿车，创建卡车，创建公交汽车等等，都属于同种类别：汽车，你难道没有想过，我把这些创建的对象在一个工厂里来负责创建，我把创建分开化，交给一人来负责，这样可以让代码更加容易管理，创建方式也可以简单点。

比如：Car    BMW=CarFactory.create(bmw);   把创建new由一个统一负责，这样管理起来相当方便

    3）怎么改进：这个时候，你会想到，创建这样同类别的东西，我把这个权利分出去，让一个人来单独管理，它只负责创建我的对象这个事情，所以你单独简历一个对象来创建同类的对象，这个时候，你想这个东西有点像工厂一样，生成同样的产品，所以取了个名字：工厂模式，顾名思义，只负责对象的创建

    4）改进后的好处：代码更加容易管理了，代码的创建要简洁很多。

    5）改进后的坏处：那就是你需要单独加一个工厂对象来负责创建，多需要写点代码。

2.一个实际的例子

   创建宝马汽车与奔驰汽车的例子

   1）先提取出一个汽车的公用接口Car

       public interface Car{

          /**行驶*/    

          public void drive();

        }

   2)宝马和奔驰汽车对象

public class BMWCar implements Car {

/**
* 汽车发动
*/
public void drive(){
   System.out.println("BMW Car drive");
}
}

public class BengCar implements Car {

/**
* 汽车发动
*/
public void drive(){
   System.out.println("BengChi Care drive");
}
}

    3)单独一个汽车工厂来负责创建

     public class FactoryCar {
/**
* 制造汽车
*
* @param company 汽车公司
* @return 汽车
* @throws CreateCarException 制造汽车失败异常
*/
public static Car createCar(Company company)throws CreateCarException{
   if(company==Company.BMW){
    return new BMWCar();
   }else if(company==Company.Beng){
    return new BengCar();
   }
   return null;
}
}

    4）最后的代码实现：

    Car BMWCar=FactoryCar.createCar(Company.BMW);
     BMWCar.drive();

   1. 我说下我对设计模式的理解：任何一样事物都是因为有需求的驱动才诞生的，所以设计模式也不例外，我们平时在编写代码的时候，随着时间的深入，发现很多代码很难维护，可扩展性级差，以及代码的效率也比较低，这个时候你肯定会想办法让代码变的优美又能解决你项目中的问题，所以在面向对象语言里，你肯定会去发现很多可以重用的公用的方法，比如：接口的存在，你自然就想到了，让你定义的方法与你的实现分开，也可以很方便把不同的类与接口匹配起来，形成了一个公用的接口，你会发现这样做，好处会是非常多的，解决了你平时想把代码的申明与逻辑实现的分开。

    2. 这个时候，你发现了，本身面向对象的语言里，已经暗藏了很多好处，你肯定会仔细去分析面向对象这个语言，认真去挖掘里面更多的奥秘，最后，你发现了，原来你可以把面向对象的特性提取成一个公用的实现案例，这些案例里能帮助你解决你平时编写代码的困扰，而这样一群人，就是所谓gof的成员，他们从平时设计建筑方面找到了灵感，建筑的设计也可以公用化以及重用化，所以他们也提取了相关的软件设计方面的公用案例，也就有了下面的相关的所谓23种设计模式，而里面这么多模式，你也可以把他们归类起来，最后发现就几类模式：创建，结构，行为等模式类别，而这些现成的方案，也可以在实际应用中充分发挥作用，随着大家的使用以及理解，发现其实这些所谓的模式里，你的确可以让你的代码变的更加优美与简练。

    3. 我比较喜欢把代码变的更加优美与简练，优美的代码就是一看就懂，结构很清晰，而简历就是一目了然，又可以解决你的问题，就是代码又少效率又高，所以平时要养成写java doc的习惯，这样的代码才为清晰，所以才会更加优美。

    4. 这些就是我对设计模式的理解，所以这么好的宝贝，我们不去深入的了解，的确可惜了，这就叫站到巨人的肩膀上.....

package com.gewara.web.module.base;

import org.apache.mina.core.service.IoHandlerAdapter;
import org.apache.mina.core.session.IoSession;

/**
 * 服务器端业务逻辑
 * 
 * @author mike
 *
 * @since 2012-3-15
 */
public class HelloServerHandler extends IoHandlerAdapter {
         @Override
        /**
         * 连接创建事件
         */
        public void sessionCreated(IoSession session){
            // 显示客户端的ip和端口
            System.out.println(session.getRemoteAddress().toString());
        }

        @Override
        /**
         * 消息接收事件
         */
        public void messageReceived(IoSession session, Object message) throws Exception{
            String str = message.toString();
            if (str.trim().equalsIgnoreCase("quit")){
                // 结束会话
                session.close(true);
                return;
            }
            
            // 返回消息字符串
            session.write("Hi Client!");
            // 打印客户端传来的消息内容
            System.out.println("Message written" + str);
        }
}

2012-03-15 14:45:41,456  INFO  logging.LoggingFilter - CREATED
/192.168.2.89:2691
2012-03-15 14:45:41,456  INFO  logging.LoggingFilter - OPENED
2012-03-15 14:45:41,487  INFO  logging.LoggingFilter - RECEIVED: HeapBuffer[pos=0 lim=11 cap=2048: 48 69 20 53 65 72 76 65 72 21 0A]
2012-03-15 14:45:41,487  DEBUG codec.ProtocolCodecFilter - Processing a MESSAGE_RECEIVED for session 1
Message writtenHi Server!
2012-03-15 14:45:41,487  INFO  logging.LoggingFilter - SENT: HeapBuffer[pos=0 lim=0 cap=0: empty]
2012-03-15 14:45:41,487  INFO  logging.LoggingFilter - RECEIVED: HeapBuffer[pos=0 lim=5 cap=2048: 71 75 69 74 0A]
2012-03-15 14:45:41,487  DEBUG codec.ProtocolCodecFilter - Processing a MESSAGE_RECEIVED for session 1
2012-03-15 14:45:41,487  INFO  logging.LoggingFilter - CLOSED

但这种模式在用户负载增加时，性能将下降非常的快。我们需要重新寻找一个新的方案，保持数据处理的流畅，很显然，事件触发机制是最好的解决办法，当有事件发生时，会触动handler,然后开始数据的处理。
Reactor模式类似于AWT中的Event处理。

Reactor模式参与者

1.Reactor 负责响应IO事件，一旦发生，广播发送给相应的Handler去处理,这类似于AWT的thread
2.Handler 是负责非堵塞行为，类似于AWT ActionListeners；同时负责将handlers与event事件绑定，类似于AWT addActionListener

并发系统常采用reactor模式，简称观察者模式，代替常用的多线程处理方式，利用有限的系统的资源，提高系统的吞吐量。

1、传输的标准格式是什么？

      是Java ObjectStream。

2、怎么样将请求转化为传输的流？

      基于Java串行化机制将请求的java object信息转化为流。

3、怎么接收和处理流？

      根据采用的协议启动相应的监听端口，当有流进入后基于Java串行化机制将流进行反序列化，并根据RMI协议获取到相应的处理对象信息，进行调用并处理，处理完毕后的结果同样基于java串行化机制进行返回。

4、传输协议是？

      tcp/ip。

原理讲了，开始实践：

创建RMI程序的6个步骤： 
1、定义一个远程接口的接口，该接口中的每一个方法必须声明它将产生一个RemoteException异常。 
2、定义一个实现该接口的类。 
3、使用RMIC程序生成远程实现所需的残根和框架。 
4、创建一个服务器，用于发布2中写好的类。 
5. 创建一个客户程序进行RMI调用。 
6、启动rmiRegistry并运行自己的远程服务器和客户程序     
    
 
1）首先创建远程接口：
 /**

•     最大的区别是与servlet成功解耦，不在依赖容器来初始化HttpServletRequest和HttpServletResponse

    struts1里依赖的核心控制器为ActionServlet而struts2依赖ServletDispatcher,一个是servlet一个是filter,正是采用了filter才不至于和servlet耦合，所有的数据 都是通过拦截器来实现，如下图显示：

•     web层表现层的丰富，struts2已经可以使用jsp、velocity、freemarker
•     线程模式方面：struts1的action是单例模式而且必须是线程安全或同步的，是struts2的action对每一个请求都产生一个新的实例，因此没有线程安全问       题。
•     封装请求参数：是struts1采用ActionForm封装请求参数，都必须继承ActionForm基类，而struts2通过bean的属性封装，大大降低了耦合。
•     类型转换：struts1封装的ActionForm都是String类型，采用Commons- Beanutils进行类型转换，每个类一个转换器；struts2采用OGNL进行类型转       换，支持基本数据类型和封装类型的自动转换。
•     数据校验：struts1在ActionForm中重写validate方法；struts2直接重写validate方法，直接在action里面重写即可，不需要继承任何基类，实际的调用顺序是，validate()-->execute()，会在执行execute之前调用validate,也支持xwork校验框架来校验。

      ◆避免对索引字段进行计算操作

◆避免在索引字段上使用not，<>，!=

◆避免在索引列上使用IS NULL和IS NOT NULL

◆避免在索引列上出现数据类型转换

◆避免在索引字段上使用函数

◆避免建立索引的列中使用空值
3.避免复杂的操作：
    ◆sql语句里出现多重查询嵌套

◆避免建立过多的表关联，较少关联关系
4.减少模糊查询：避免使用like语句，尽量把结果比较放到应用服务器端，通过java代码过滤
5.WHERE的使用
    ◆避免对where条件采用计算
        ◆避免在where条件中使用in,not in,or或则havin,可以使用 exist 和not exist代替 in和not in

    ◆不要以字符格式声明数字，要以数字格式声明字符值，否则索引将失效
6.采用临时表

•     优化数据库服务器端的配置参数
•     应用服务器端数据连接池的配置参数修改
•     应用服务器端的sql审核,建立更好的索引以及修改不好的sql语句：关联表过多，查询的数据量过大，表设计不合理等
•     应用服务器端拆解过大的表，分为多张表，甚至把一个数据库分为多个数据库
•     数据库服务器端拆解为读/写分离，Master/Slave方式，一台写主机对应两台或则多台读的备用机器

•     访问压力过大，1台机器不能承受，该为多台机器，应用服务器配置为集群模式