java 设计模式-接口型模式

最新推荐文章于 2024-07-30 13:31:45 发布

意亦逸

最新推荐文章于 2024-07-30 13:31:45 发布

阅读量1k

点赞数

分类专栏： java 文章标签： java 设计模式

java 专栏收录该内容

24 篇文章 0 订阅

订阅专栏

接口型模式

接口与抽象类的区别：
一个类可以实现（implements）任意多个接口，但只能继承（extend）一个抽象类。一个抽象类可有非抽象方法，可以定义构造器，接口的所有方法都是抽象的。接口只能声明static final 常量，因为一般成员变量无法实例化。抽象类的方法可以是private public protected 或者默认的package接口的方法都是public。

适配器模式

类适配器，对象适配器
类适配器是客户类有一个接口规范的情况下可用，此时适配类只需作为功能类的子类，并实现接口并可，直接用功能类实现了客户类的要求，而对象适配类是在客户类没有提供接口的情况下用的，适配类作为客户类的子类，并在其中实例化一个功能类的对象，并调用此对象的方法实现适配，故称对象适配。

//客户类
public class Customer
{
    public virtual int CustomMethod();
}

//已有功能类
public class Action
{
    public Action()...{};
    public int ActionMethod()
    {
         //do something here
    }
}

//对象适配器
public class AdapterClass extents Customer
{
    private Action ac;
    public AdapterClass()...{};
    public override void CustumMethod()
    {
        retun ac.ActionMethod();
    }
}

//客户接口
public Interface ICustomer
{
public int CustomMethod();
}

//已有功能类
public class Action
{
public Action(){};
public int ActionMethod()
{
//do something here
}
}

//类适配器
public class AdapterClass extents Action implements ICutomer
{
public AdapterClass(){};
public void CustumMethod()
{
retun ActionMethod();
}
}

个人认为，在java中，由于不可多继承故存在类适配器与对象适配器的的区别。在C++中区别不大（个人见解，若有错海涵）。

外观模式

Facade（外观）模式为子系统中的各类（或结构与方法）提供一个简明一致的界面，隐藏子系统的复杂性，使子系统更加容易使用。
Facade模式概述
实际应用中，我们在对付一些老旧的code（尤其是将C的代码转成C++代码）或者即便不是老旧code，但涉及多个子系统时，除了重写全部代码（对于老旧code而言），我们还可能采用这样一种策略：重新进行类的设计，将原来分散在源码中的类/结构及方法重新组合，形成新的、统一的接口，供上层应用使用。
这在某种意义上与Adapter及Proxy有类似之处，但是，Proxy（代理）注重在为Client-Subject提供一个访问的中间层，如CORBA可为应用程序提供透明访问支持，使应用程序无需去考虑平台及网络造成的差异及其它诸多技术细节；Adapter（适配器）注重对接口的转换与调整；而
Facade所面对的往往是多个类或其它程序单元，通过重新组合各类及程序单元，对外提供统一的接口/界面。
Facade模式应用
在遇到以下情况使用Facade模式：
　　1、当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
　　2、客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
　　3、当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点，如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。

Facade模式优缺点
Facade模式有下面一些优点：
　　1、它对客户屏蔽子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
　　2、它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。Facade模式有助于建立层次结构系统，也有助于对对象之间的依赖关系分层。Facade模式可以消除复杂的循环依赖关系。这一点在客户程序与子系统是分别实现的时候尤为重要。在大型软件系统中降低编译依赖性至关重要。在子系统类改变时，希望尽量减少重编译工作以节省时间。用Facade可以降低编译依赖性，限制重要系统中较小的变化所需的重编译工作。Facade模式同样也有利于简化系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。

合成模式

//转载自 http://blog.csdn.net/jason0539/article/details/22642281
将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性
1.组合模式的例子
这里写图片描述

import java.util.ArrayList;  
import java.util.List;  

public class ComponentDemo {  
    public abstract class Component {  
        String name;  

        public abstract void add(Component c);  

        public abstract void remove(Component c);  

        public abstract void eachChild();  
    }  

    // 组合部件类  
    public class Leaf extends Component {  

        // 叶子节点不具备添加的能力，所以不实现  
        @Override  
        public void add(Component c) {  
            // TODO Auto-generated method stub  
            System.out.println("");  
        }  

        // 叶子节点不具备添加的能力必然也不能删除  
        @Override  
        public void remove(Component c) {  
            // TODO Auto-generated method stub  
            System.out.println("");  
        }  

        // 叶子节点没有子节点所以显示自己的执行结果  
        @Override  
        public void eachChild() {  
            // TODO Auto-generated method stub  
            System.out.println(name + "执行了");  
        }  

    }  

    // 组合类  
    public class Composite extends Component {  

        // 用来保存节点的子节点  
        List<Component> list = new ArrayList<Component>();  

        // 添加节点 添加部件  
        @Override  
        public void add(Component c) {  
            // TODO Auto-generated method stub  
            list.add(c);  
        }  

        // 删除节点 删除部件  
        @Override  
        public void remove(Component c) {  
            // TODO Auto-generated method stub  
            list.remove(c);  
        }  

        // 遍历子节点  
        @Override  
        public void eachChild() {  
            // TODO Auto-generated method stub  
            System.out.println(name + "执行了");  
            for (Component c : list) {  
                c.eachChild();  
            }  
        }  
    }  

    public static void main(String[] args) {  
        ComponentDemo demo = new ComponentDemo();  
        // 构造根节点  
        Composite rootComposite = demo.new Composite();  
        rootComposite.name = "根节点";  

        // 左节点  
        Composite compositeLeft = demo.new Composite();  
        compositeLeft.name = "左节点";  

        // 构建右节点，添加两个叶子几点，也就是子部件  
        Composite compositeRight = demo.new Composite();  
        compositeRight.name = "右节点";  
        Leaf leaf1 = demo.new Leaf();  
        leaf1.name = "右-子节点1";  
        Leaf leaf2 = demo.new Leaf();  
        leaf2.name = "右-子节点2";  
        compositeRight.add(leaf1);  
        compositeRight.add(leaf2);  

        // 左右节点加入 根节点  
        rootComposite.add(compositeRight);  
        rootComposite.add(compositeLeft);  
        // 遍历组合部件  
        rootComposite.eachChild();  
    }  
}

3.什么情况下使用组合模式

   引用大话设计模式的片段：“当发现需求中是体现部分与整体层次结构时，以及你希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑组合模式了。”

桥接模式

//转自 http://blog.csdn.net/hfmbook/article/details/7702642
暂未理解照搬

 public interface Qiao {
     //目的地B
     void targetAreaB();
 }

/**
 * 目的地B1
 */
public class AreaB1 implements Qiao {

    @Override
    public void targetAreaB() {
        System.out.println("我要去B1");
    }

}

/**
 * 目的地B2
 */
public class AreaB2 implements Qiao {

    @Override
    public void targetAreaB() {
        System.out.println("我要去B2");
    }

}

/**
 * 目的地B3
 */
public class AreaB3 implements Qiao {

    @Override
    public void targetAreaB() {
        System.out.println("我要去B3");
    }

}

 public abstract class AreaA {
     //引用桥接口
     Qiao qiao;
     //来源地
     abstract void fromAreaA();
 }

/**
 * 来源地A1
 */
public class AreaA1 extends AreaA {

    @Override
    void fromAreaA() {
        System.out.println("我来自A1");
    }

}

/**
 * 来源地A2
 */
public class AreaA2 extends AreaA {

    @Override
    void fromAreaA() {
        System.out.println("我来自A2");
    }

}

/**
 * 来源地A3
 */
public class AreaA3 extends AreaA {

    @Override
    void fromAreaA() {
        System.out.println("我来自A3");
    }

}

public class Clienter {
    public static void main(String[] args) {
        AreaA a = new AreaA2();
        a.qiao = new AreaB3();
        a.fromAreaA();
        a.qiao.targetAreaB();
    }
}

注意点：

　　　　1、定义一个桥接口，使其与一方绑定，这一方的扩展全部使用实现桥接口的方式。

　　　　2、定义一个抽象类，来表示另一方，在这个抽象类内部要引入桥接口，而这一方的扩展全部使用继承该抽象类的方式。

　　其实我们可以发现桥接模式应对的场景有方向性的，桥绑定的一方都是被调用者，属于被动方，抽象方属于主动方。

　　其实我的JDK提供的JDBC数据库访问接口API正是经典的桥接模式的实现者，接口内部可以通过实现接口来扩展针对不同数据库的具体实现来进行扩展，而对外的仅仅只是一个统一的接口调用，调用方过于抽象，可以将其看做每一个JDBC调用程序（这是真实实物，当然不存在抽象）

　　下面来理解一下开头的概念：

　　桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。

　　这种模式涉及到一个作为桥接的接口，使得实体类的功能独立于接口实现类。这两种类型的类可被结构化改变而互不影响。

　　理解：此处抽象化与实现化分别指代实例中的双方，而且实现化对应目的地方（通过实现桥接口进行扩展），抽象方对应来源地方（通过继承抽象类来进行扩展），如果我们不使用桥接模式，我们会怎么想实现这个实例呢？很简单，我们分别定义来源地A1、A2、A3类和目的地B1、B2、B3，然后具体的实现就是，A1到B1一个类，A1到B2一个类，等，如果我们要扩展了A和B ,要直接增加An类和Bn类，如此编写不说类内部重复性代码多，而且还会导致类结构的急剧膨胀，最重要的是，在通过继承实现路径的时候，会造成双方耦合性增大，而这又进一步加剧了扩展的复杂性。使用桥结构模式可以很好地规避这些问题：重在解耦。