什么是接口（中级篇）——接口在设计模式中的使用（二）

标签：

还记得我的软件工程老师是这么说的：软件应该往高内聚，低耦合的方向进行设计。

当时，还身为一个初学者的我，不太明白老师的这句话——既然面向对象提供给了我们”继承“这种高耦合的概念，那为何我们还要低耦合高内聚呢？难道放着继承的概念不用，而改为面向过程吗？

带着这一疑问，我请教了我的老师，他给我的回答是：通过接口来分隔分离逻辑，就可以达到低耦合的效果。

我们来回顾一下前一篇所学习的"控制反转"设计思想，其实质就是上面所说的"通过接口来分离逻辑"。

但以上一篇的示例来说，达到这个目标，还有一些欠缺，首先让我们来回顾一下上一篇的代码内容

/// <summary>
/// 这是一个负责登录的接口类型
/// </summary>
public interface ILoginChecker
{
    /// <summary>
    /// 登录，需要的参数是用户名和密码，需要返回一个bool类型表示登录是否成功
    /// </summary>
    /// <param name="loginName"></param>
    /// <param name="password"></param>
    /// <returns></returns>
    bool Login(string loginName, string password);
}

public class LoginWindow : Form
{
    private ILoginChecker loginChecker;
    
    /// <summary>
    /// 通过构造函数决定使用哪个ILoginChecker来负责登录流程
    /// </summary>
    /// <param name="chcker"></param>
    public LoginWindow(ILoginChecker chcker)
    {
        this.loginChecker = chcker;
    }

    void LoginButton_Click(object sender, EventArgs e)
    {
        string loginName = null, password = null;
        //从控件上取值
        //判断空值
        //等一切OK时
        if (this.loginChecker.Login(loginName, password))
        {
            //登录成功
        }
        else
        {
            //登录失败
        }
    }
}

肯定会有一些人带着这样的疑问：在代码的某个地方一定写着类型这样的内容：

///实例化某个实现了ILoginChecker接口的类型
ILoginChecker checker = new XXXLoginChecker();
LoginWindow window = new LoginWindow(checker);
window.Show();

那么随着以后功能的更新，在不断地修改这里的ILoginChecker checker = new XXXLoginChecker();

时间久了，记不得这段代码写在哪儿，也是很头疼的一件事，最重要的是，依然没达到”易维护“的效果，和之前相同，每次的须求改更，或是环境变化，都需要重写这句话。

如果能有一个容器，能够在运行时（注1）判断使用哪个ILoginChecker类型，那就方便多了。

运行时：与"编译时"相对应，比如我说定义一个变量Int32 i，这个i的类型就是Int32，这是在编译时决定的，因为程序在由代码编译为程序时，已经可以确定i就是一个Int32类型了。

再比如说我定义一个变量Object obj，这个obj的类型虽然是Object，但是会根据实际的赋值，发生类型的变换，而赋的什么值给它，程序在编译时是无法得知的，只有在运行到这里的时候才能知道，这就叫运行时。

我们来假设一个现实场景：

场景中，我们把ILoginChecker这个接口

1、门卫是由保安公司派出的

2、保安公司根据每个需求方的要求不同，配备不同的保安

3、保安公司拥有满足各种需求的保安

这样一来，我们就要再补充一个相当于是保安公司的类型了，用来创建ILoginChecker实例

所以我们起个名字叫LoginCheckerFactory

里面只有一个主要方法：CreateLoginChecker，根据我们指定的名称，返回一个具体的IloginChecker实例，我们来看一下示例代码：

class LoginCheckerFactory
{
    public ILoginChecker CreateLoginChecker(string checkerName)
    {
        switch (checkerName)
        {
            case "Database": return new DatabaseLoginChecker(); //由数据库完成的登录验证
            case "WebService": return new WebServiceLoginChecker(); //由WebService完成的登录验证
            case " TCP": return new TCPLoginChecker(); //由TCP通讯完成的登录验证
            default: throw new ApplicationException("不存在这个名称的Checker实例");
        }
    }
}

此时，你会发现，登录的判定流程是依赖于一个字符串，Database或WebService或TCP。到了这一步，我想大部分人都明白，这个字符串只要写在配置文件里，就大功告成了。

然后项目发布，在不同的运行环境中间，我只需要改一下配置文件，就能实现各种方式的登录了。

对于更新与维护是同样的便捷，你可以把不同版本的ILoginChecker都放在这个工厂里，然后根据外部的一些版本号来更改实例。

在BUG的修正中，你也不必直接修改类型本身，可以拷备一个出来，比如叫WebServiceLoginChecker2，这样即保证了程序原有的可运行性，又可以进行BUG的修正，一旦出现了”动一发触全身“的情况，也非常容易全身而退。

这样的设计思想、模式，我们将其称之为工厂模式。工厂模式还分为简单工厂模式和抽象工厂模式，但是其最核心的思想，就是创建一个工厂，由工厂在运行时，进行动态的实例创建、返回。大大降底的类与类、模块与模块之间的耦合度，为更新与维护提供了非常好的隔离环境。

小结

通过第一、第二篇文章的学习，一种初步的构架思路已经产生。

1、分析当前方法要的主要事情

2、将可能存在变更的逻辑，建立接口，待以后实现

3、考虑到上述接口的实现多样性，建立工厂类型，由工厂类型负责创建接口实例

利与弊的权衡

从做产品的角度考虑，一个好的基本构架是产品最核心的保障，有了这样的保障，可以说，除非到你换语种的那一天，否则永远不会存在（推倒重来）的那一天，因为你的每一个环节都被低耦合了，它们全部都可以被单独替换。

从做项目的角度考虑，一个好的基本构架是项目中最耗时间、最耗成本的阶段。在面向结果的项目负责人眼中，相对于可维护性进度才是最重要的，所以在做项目这种情况下，对使用架构应该进行一个速与质的权衡。

文章为作者原创，转载请标明出处，谢谢  http://www.cnblogs.com/ShimizuShiori/p/4929300.html

什么是接口（中级篇）——接口在设计模式中的使用（二）

标签：

原文地址：http://www.cnblogs.com/ShimizuShiori/p/4929300.html