1.3　EIT造型

EIT造型是高焕堂老师在讲解Android架构时提到的一种用于表述类与类之间关系纽带的概念，这种纽带把本无关系的单个类变成了联系密切的“亲戚”。

1.3.1　EIT是什么

从类方法与UML类图中可以抽离出一个标准模板，暂且称这个标准模板为公式。只要有公式，就能很好地理解自变量与因变量之间的关系。

例如，力矩与力臂的关系公式 M = FL ，可以理解为力臂（ L ）一定的时候，力（ F ）越大，力矩（ M ）越大；又如，力与加速度的关系公式 F = ma ，可以理解为物体加速度（ a ）跟作用力（ F ）成正比，跟物体的质量（ m ）成反比，且与物体质量的倒数成正比。

把这种自变量与因变量之间的关系应用于软件设计，是否也能找到一种类似的“公式”，以便我们理解代码与框架之间是如何“沟通”的呢？答案是肯定的，这就是高焕堂老师讲解Android架构时提出的EIT造型，这种造型也是代码设计时用的一种标准“公式”。

EIT造型由以下3部分组成。

E : Engine，即引擎，基类。I : Interface，即接口。T : Tire，即轮胎，派生类。

引擎通过接口驱动轮胎带动整辆车往前行驶，EIT造型的形象表示如图1-9所示。

图1-9形象地描述了EIT造型的3种组成部分之间的关系，中间的接口I用以联系引擎E和轮胎T，应用在软件设计中，则是基类E和派生类T之间的联系通过接口I来实现。

1.3.2　程序应用

EIT造型迁移到编程实践中，E是基类、I是接口、T是派生类，应用到1.1节的Car类的案例中，Car是E、SetDiffTire（string tire）是I、DZ是T，用UML类图表示的EIT造型如图1-10所示。

图1-10说明了EIT造型的程序应用，基类Car是EIT造型中的E，基类中的虚方法SetDiffTire（string tire）是EIT造型中的I，派生类DZ是EIT造型中的T，派生类实现具体的SetDiffTire(string tire)（接口I）。

图1-10中，Car与DZ紧耦合，在软件设计中可以继续优化，将Car与DZ分离（解耦），增加一个接口类SetTireInterface，在Car类中实现安装不同轮胎的方法DiffTire（；）各个派生类继承接口类，例如，DZInterface派生类继承自接口类SetTireInterface，DZInterface派生类“安装”符合自身应用需求的Tire，具体代码如下。

//新增接口类
class SetTireInterface
{
    public:
        SetTireInterface(string tn):m_tireName(tn){}
        virtual string SetDiffTire()=0;
    protected:
        string m_tireName;
};
//新增接口派生类
class DZInterface:public SetTireInterface
{
    public:
        DZInterface(string tn):SetTireInterface
        (tn){}
        string SetDiffTire()
        {
            return m_tireName;
        }    
};
//Car与DZ解耦
class Car
{
    public:
        Car(string en):engineName(en)
        {
            m_Interface=new DZInterface("miqilin");
        }
        void SetCommonEngine()
        {
            cout<<"commonEngine is: "<< engineName<<endl;
        }
        void DiffTire()
        {   
           
            cout<<m_Interface->SetDiffTire()<<endl;
        }
    protected:
        string engineName;
        SetTireInterface* m_Interface;
};
//客户端主程序
int main()
{
    Car *car=new Car("weichai");
　
    car->SetCommonEngine();
    car->DiffTire();
    delete car;
}

1.3.3　优化设计

1.3.2小节中对最初的Car类进行了设计，并且完成了对应的代码，根据1.3.2小节代码中的各个类的组成及类间关系，绘制优化设计后的EIT造型的UML类图，如图1-11所示。

与图1-10相比，优化后的EIT造型多了一个接口类对象SetTireInterface（EIT中的I），这个接口类对象替代了原来的接口方法SetDiffTire（string tire)；EIT中的E和T保持不变，并且在E的Car对象中包含接口类对象SetTireInterface的成员变量，Car对象中的接口类对象SetTireInterface在构造Car对象的同时被赋值为m_Interface，并且在调用Car对象的DiffTire(）方法中完成对SetDiffTire()的间接控制。

但是，这个优化后的SetTireInterface与DZInterface仍然存在继承泛化关系，能否将两者改成关联关系呢？这里考虑将接口及派生类分离成两个独立类，整个流程代码完善后的结果如下。

#include <iostream>
#include <cstring>
#include <algorithm>
　
using namespace std;
　
class SetTireInterface;
//派生类DZ对象
class DZ
{
    public:
        DZ(){}
        void SetDiffTire(string tire)
        {
            cout<<"setDiffTire is: "<<tire<<endl;;
        }
};
//派生类对象独立于接口类
class SetTireInterface
{
    public:
        SetTireInterface()
        {
            m_dzInterface=new DZ();
        }
        void EnableSetDiffTire(string tire)
        {
            m_dzInterface->SetDiffTire(tire);
        }
    protected:
        DZ* m_dzInterface;
};
//Car类与接口单向关联
class Car
{
    public:
        Car(string en):engineName(en)
        {
            m_Interface=new SetTireInterface();
        }
        void SetCommonEngine()
        {
            cout<<"commonEngine is: "<< engineName<<endl;
        }
        void DiffTire(string tire)
        {   
           
            m_Interface->EnableSetDiffTire(tire);
        }
    protected:
        string engineName;
        SetTireInterface* m_Interface;
};
//客户端主程序
int main()
{
    Car *car=new Car("weichai");
　
    car->SetCommonEngine();
    car->DiffTire("miqilin");
    delete car;
}

去除继承泛化关系后的优化方案的代码如上，根据以上代码绘制的UML类图如图1-12所示。

图1-12说明了再次优化后由继承泛化关系变成关联关系的EIT造型的组成，Car对象与SetTireInterface对象为单向关联关系，Car对象包含SetTireInterface对象的成员变量，成员函数与图1-11保持一致；DZ对象与SetTireInterface对象为双向关联关系，DZ对象包含SetTireInterface对象的成员变量，SetTireInterface对象包含DZ对象的成员变量，SetTireInterface对象的成员方法EnableSetTireInterface(string tire）中完成对SetDiffTire（string tire）的关联控制。

图1-12中，Car、SetTireInterface、DZ之间的关联替代图1-11中SetTireInterface与DZInterface之间的继承泛化，使SetTireInterface与DZ实现解耦，方便后续开发者对程序进行扩展和维护，实现可靠、完美的软件设计。