老狼博客

装饰者模式的目标就是扩展的功能可以被适用在一个特定的实例，而且同时可以能够创建一个不具备这个扩展功能的 原始实例。装饰者模式同时允许为一个实 例使用多个装饰者类，这样你就不必纠缠于为每个实例创建一个装饰者类。这个模式在继承时是可选择的，继承指的是你可以从一个父类中继承父类的功能。不同于 继承在编译时添加行为，在情况允许下，装饰允许你在运行时添加一个新的行为。

我们可以根据以下几步实现装饰者模式：

1. 创建一个装饰者类继承原始组件。

2. 在装饰者类中，添加一个组件域。

3. 在装饰者类的构造函数中初始化这个组件。

4. 在装饰者类中，重新将所有的调用新组件的方法。

5. 在装饰者类中，重写所有需要改变行为的组件方法。

工厂模式是我们最常用的设计模式，学好这个模式当然可以事半功倍，不用关心如何创建，只需要根据相应的需求去 获取相应的对象。 假如我们现在需要得到一个Ipod对象和Mac对象，可能在之前，我们的Ipod和Mac都是new出来了，相当于我们的程序依赖了Ipod类和Mac， 但是使用了工厂我们就可以部分解耦，将创建和使用分离。 设计模式有一条原则，对象要么构造其他对象，要么使用其他对象，绝对不要两者兼顾。如果遵守这一约束，最终可以降低耦合度。

1、简单工厂

public class AppleSimpleFactory {
        private static Map beanMap = new HashMap();
        public Object getBean(String beanName) {
        if(beanMap.containsKey(beanName)) {
            returnbeanMap.get(beanName);
        }
    return null;
    }
    public void init() {
        beanMap.put("Ipod", newIpod());
        beanMap.put("Mac", newMac());
    }
 }

2、抽象工厂abstract factory

抽象工厂类似于将工厂再抽象一层，让关注点不在于怎么创建，而在于创建不同的方式。 例如，A工厂生产ipod的时候需要打印A的牌子，而B工厂生产的时候需要打B的牌子，生产的产品都是一样的，都是ipod，但是其中的工序和方式不同

public abstract class MyAbstractFactory {
   protected static MapbeanMap =new HashMap();
   public abstract void create();
   public abstract Product getProduct(String className);
}
 
public class MyAbstractFactoryImpl extends MyAbstractFactory {
   @Override public void create() {
      Ipod iPod =newIpod();
      iPod.pasteSign("made by A factory");
      beanMap.put("Ipod", newIpod());
      beanMap.put("Mac", newMac());
   }
 
   @Override public Product getProduct(String className) {
            if(beanMap.containsKey(className)) {
            return (Product)beanMap.get(className);
      }
      returnnull;
   }
}

工厂方法类似，其中最主要的就是贴牌的不同。 抽象工厂用于创建相同的产品但是方式不同的地方。

spring 的beanFactory

在 Spring 中，两个最基本最重要的包是 org.springframework.beans 和 org.springframework.context 。这两个包中的代码为 Spring 的控制反转特性（也叫作依赖注入）提供了基础。 BeanFactory 提供了一种先进的配置机制来管理任何种类 bean (对象)，这种配置机制考虑到任何一种可能的存储方式。 ApplicationContext 建立在 BeanFactory 之上，并增加了其他的功能，比如更容易同 Spring AOP 特性整合， 消息资源处理（用于国际化），事件传递，以声明的方式创建 ApplicationContext， 可选的父上下文和与应用层相关的上下文（比如WebApplicationContext），以及其他方面的增强。 简而言之，BeanFactory 提供了配置框架和基本的功能， 而 ApplicationContext 为它增加了更强的功能，这些功能中的一些或许更加接近 J2EE 并且围绕企业级应用。

一 般来说， ApplicationContext 是 BeanFactory 的完全超集， 任何 BeanFactory 功能和行为的描述也同样被认为适用于 ApplicationContext 用户有时不能确定 BeanFactory 和 ApplicationContext 中哪一个在特定场合下更适合。 通常大部分在 J2EE 环境的应用中，最好选择使用 ApplicationContext ， 因为它不仅提供了 BeanFactory 所有的特性以及它自己附加的特性，而且还提供以声明的方式使用一些功能， 这通常是令人满意的。 BeanFactory 主要是在非常关注内存使用的情况下 （比如在一个每 kb 都要计算的 applet 中）使用，而且你也不需要用到 ApplicationContext 的所有特性。

表述一个适配器类的另外一个术语是封装，表示允许你把行为封装到一个类中，并且在正确的情形下重用这些行为。 一个经典的例子，当你为表创建一个领域 类，你可以使用一个适配器类封装所有的方法到一个方法中，而不是调用不同的表并且一个一个的使用它们的方法。这不仅允许你重用你想使用的任何行为，如果你 需要在不同的地方使用相同的行为的话，同样使你不必重写代码。

例如：

和尚接口: 

public interface 和尚 {
    void 吃斋();
    void 打坐();
    void 练武();
    void 睡觉();
} 

作为适配器的抽象类 天星 

public abstract class 天星 implements 和尚 { 

 public void 吃斋() { 

    } 

    public void 打坐() { 

    } 

    public void 睡觉() {

    }
    public void 练武() { 

    }
}

然后是具体实现 鲁智深 

public class 鲁智深 extends 天星 {
    public void 练武（）{ 

    }
}

环境：当你在执行数据库的CRUD的时，其中添加和修改都是同一个对象，那么这样的话就可以考虑使用策略模式。

class CRUD{

public void savaOrUpdate(Entity obj){

if(obj.getId()!=null && obj.getId>0){

//TODO update()

}else{

//TODO save()

}

}

1、为什么要使用单例模式
如果要读取资源文件
class ReadConfig{
public String xxxx;
public ReadConfig{
//构造方法读取配置文件
}
}
然后创建对象 ReadConfig rc=new ReadConfig();
使用rc.xxxx就可以读取ReadConfig的属性
问题出现了，如果系统中有多个地方用到此对象，那么内存中就会出现多个ReadConfig
为了避免内存的浪费，那么系统只需要实例化一个ReadConfig对象就可以。

2、怎么使用

出现多次实例化对象的情况主要原因是public，而且单例模式最主要的收回用户实例化的权限，而且通过一个getinstance的方法来访问唯一实例

2.1 懒汉模式：

class ReadConfig{
private static ReadConfig reqinstance=null;
private ReadConfig{

}

public static synchronized ReadConfig getinstance()
{
if(reqinstance==null){
reqinstance=new ReadConfig();
}
return reqinstance;
}
}

2.2饿汉模式：

class ReadConfig{
private static ReadConfig reqinstance=new ReadConfig();
private ReadConfig{

}
public static ReadConfig getinstance(){
return reqinstance;
}

}