业务逻辑的强类型化（续）

作为一个好事者，我希望能够给我周边的人讲解这种技术。他们对C++很不熟悉，但熟悉C#。于是，我打算把这种技术移植到C#中，以便於讲解。说做就做。

我建了一个C#项目，把代码拷贝过去，然后着手修改，这样可以省些事。我立刻便遇到了问题。C#有泛型，相当于模板，但不支持非类型泛型参数，即int CurrType，只允许用一个类型作为泛型参数。这样我们就不能使用C++中耍的手法了（typedef currency<n>）。退而求其次，直接用类实现货币类型：

class RMB

{

public double _val;

}

class USD

{

public double _val;

}

…

这样太繁琐了，很多重复。我们可以用一个基类封装_val，货币类从基类上继承获得：

class CurrBase

{

public double _val;

}

class RMB : CurrBase

{

}

class USD : CurrBase

{

}

…

货币类都是空的，它们的存在只是为了创建一个新的类型。

现在处理货币转换问题。C#不能重载operator=，所以只能使用一个helper函数泛型asign代替：

class utility

{

     public static void asign<T1, T2>(T 1 c 1, T 2 c 2)

         where T1 : CurrBase

         where T2 : CurrBase

     {

         c1._val = c2._val * utility.e_rate[c2.CurID(),c1.CurID()];

     }

}

这个asign函数是个泛型，泛型参数分别代表了两个操作数，函数中执行了货币转换。为了能够在汇率表中检索到相应的汇率，我们必须为基类和货币类定义抽象函数：

    public abstract class CurrBase

    {

        public double _val=0;

        public abstract int CurID();

    }

    public class RMB : CurrBase

    {

        public override int CurID()

        {

            return 0;

        }

}

…

基类中声明了CurID()抽象方法，并在货币类中定义。这样，便可以用统一的方式进行货币转换了：

asign(rmb_, usd_);

还行，尽管不那么漂亮，但也还算实用。不过，当我多看了几眼代码后，便发现这里根本没有必要使用泛型。完全可以利用OOP的多态实现同样的功能：

     public static void asign(CurrBase c1, CurrBase c2)

     {

         c1._val = c2._val * utility.e_rate[c2.CurID(),c1.CurID()];

     }

不过也没关系，使用方式还没有变，代码反而更简单了。使用泛型毕竟不是我们的根本目的，对吧？

现在轮到运算符了。不过我不知该把泛型运算符定义在哪里。按C#文档里的要求，运算符必须是类的static成员。但我的泛型运算符是针对许多个货币类的，定义在任何一个中，对其他类似乎不太公平。于是，我决定尝试将其定义在基类里：

    public abstract class CurrBase

{

   …

        public static CurrBase operator+<T1, T2>(T 1 c 1, T 2 c 2)

           where T1 : CurrBase

           where T2 : CurrBase

        {

            …

        }

}

编译器立刻还我以颜色：操作符根本不能是泛型！好吧，不能就不能吧，继续退而求其次，用OOP：

    public abstract class CurrBase

{

   …

        public static CurrBase operator+(CurrBase c1, CurrBase c2)

        {

            …

        }

}

不过，这次让步让得有点离谱。当我写下这样的代码时，编译器居然不认账：

rmb_=rmb_+usd_;

错误信息是：错误 CS0266: 无法将类型“st_in_cs.CurrBase”隐式转换为“st_in_cs.RMB”。存在一个显式转换(是否缺少强制转换?)。

我非得采用强制类型转换，才能过关：

rmb_=(RMB)(rmb_+usd_);

太夸张了，这样肯定不行。于是，我被迫在每个货币类中定义operator+：

class RMB : CurrBase

{

…

   public RMB operator+(RMB c1, USD c2)

   {

       …

   }

   public RMB operator+(RMB c1, UKP c2)

   {

       …

   }

…

}

这可不得了，我必须为每对货币类定义一个+操作符，+操作符的总数将会是货币类数量的平方！其他的操作符每个都是货币类数的平方。我可受不了！

好在，可爱的OOP为我们提供了一根稻草，使得每个货币类的每个操作符只需定义一个：

class RMB : CurrBase

{

…

   public RMB operator+(RMB c1, CurrBase c2)

   {

       …

   }

…

}

这样，任何货币类都可以作为第二操作数参与运算，而操作符只需定义一个。这样的工作量，对于一个逆来顺受的程序员而言，还是可以接受的。很好，代码不出错了：

rmb_=rmb_+usd_;

但当我写下如下代码时，编译器又开始抱怨了：

ukp_ = rmb_ + usd_;

还是要求显示转换，除非我们为UKP定义隐式类型转换操作符：

class UKP

{

…

    public static implicit operator UKP(RMB v)

    {

        …

    }

…

}

光有RMB的不行啊，还得有USD的、JPD…。不过这样的话，我们必须为每一个货币类定义所有其它货币类的类型转换操作符。又是一个组合爆炸。到这里，我已经黔驴技穷了。谁让C#不支持=操作符重载和操作符模板化呢。没办法，只能忍着点了。

不过，如果我们能够降低点要求，事情还是有转机的。如果我们不通过操作符，而是采用static成员方法，进行货币的运算的话，就可以省去很多代码了：

    public class utility

    {

        public static T1 asign<T1, T2>(T 1 c 1, T 2 c 2)

            where T1 : CurrBase, new()

            where T2 : CurrBase

        {

            c1._val = c2._val * utility.curr_rate[c2.CurID(),c1.CurID()];

            return c1;

        }

        public static T1 add<T1, T2>(T 1 c 1, T 2 c 2)

            where T1 : CurrBase, new()

            where T2 : CurrBase

        {

            T1 t=new T1();

            t._val=c1._val + c2._val *

               utility.curr_rate[c2.CurID(),c1.CurID()];

            return t;

        }

       …

}

这里，我还是使用了泛型，因为这些函数需要返回一个值，只有使用泛型，才能返回一个明确的类型，以避免强制转换的要求。于是，赋值和计算的代码就成了：

asign(jpd_, asign(ukp_, add(rmb_, usd_)));//也就是jpd_=ukp_=rmb_+usd_

的确是难看了点，但是为了能够少写点代码，这也只能将就了。

好了，我尽了最大的努力，试图在C#中实现强类型、可计算的货币系统。尽管最终我可以在C#中开发出一组与C++具有相同效果的货币类（除了赋值操作以外），但需要我编写大量的代码，实现各种计算操作，以及货币类之间的类型转换操作（组合爆炸）。相比C++中总共200来行代码，的确复杂、臃肿得多。

我并不希望把这篇文章写成“C++ vs C#”，（尽管我很高兴看到C++比C#强J）。我希望通过对这样一个代码优化任务，显示不同技术运用产生的结果。同时，也可以通过这两种实现尝试的对比，了解泛型编程的作用，以及泛型编程对语言提出的要求。

毋庸置疑，C++采用了纯粹的泛型编程，因此可以对问题进行高度抽象。并利用问题所提供的每一点有助于抽象的信息，以最简的形式对问题建模。而作为以OOP为核心的语言C#，对泛型的支持很弱。更重要的是，C#的泛型对泛型参数的运用严重依赖於泛型参数的约束（where）。如果没有where，C#将泛型参数作为Object类型处理，此时泛型参数没有意义（我无法访问该类型的成员）。如果有了where，C#要求泛型参数必须同where中指定的类型有继承关系（如asign中的T1必须是CurrBase的继承类）。而泛型函数中对泛型参数的使用也局限在约束类型（即CurrBase）上。于是，我们可以直接用以基类（CurrBase）为参数的asign函数代替泛型版本的asign。由于C#对泛型参数的继承性要求，使得泛型被困住了手脚，无法发挥应用的作用。正由于这些问题，C++才采用了现在模板的形式，而没有采用同C#一样的泛型模式。

或许有人会说，既然OOP能解决问题（asign最初不需要泛型也行，但最终还需要泛型来控制返回值的类型），为什么还要GP呢？

对于这个问题，前面也给出了答案。由于C#的泛型不支持非类型泛型参数，因此迫使我们使用传统OOP的手段：利用基类实现货币类的实现，定义货币类来创建新类型，使货币强类型化，利用虚函数提供货币独有信息。仅这一层面，OOP方式已经大大不如GP方式了，GP仅定义了一个模板，所有的货币类型都是通过typedef一句语句产生，无需更多的代码。而OOP方式要求必须为每一个货币编写一个类，代码量明显多于GP方式。

此后，C++通过重载一组操作符模板，实现货币的运算。而货币模板以及生成货币类型的typedef都无须任何改变。而在C#中，由于不支持泛型操作符，被迫定义大量的特定于类型的操作符。所有运算操作符，在每个货币类中都必须重载一次。而转型操作符，则必须在每个货币类中重载n-1次。

换句话说，有n种货币，有m个操作符（包括转型操作符），那么就需要定义n+1个类（包括基类），n×m+n×(n-1)个操作符。假设n=10，m=10，那么总共需要11个类定义，190个操作符重载！如果每个类定义需要20行代码，而每个操作符重载需要5行代码，那么总共需要1170行代码。如果货币数量增加，总的代码数将以几何级数的方式增长。

上面的计算表明，尽管 OOP 可以解决问题，实现我们的目标，但所带来的开发量和维护量却是难以承受的。而且， OOP 的方式扩展非常困难，随着系统规模的扩大，扩展将越来越困难。所有这些都表明一点，尽管 OOP 是软件工程的明星，但在实际情况下，很多地方存在着 OOP 无法解决或难以解决的问题。这也就是为什么业界的先锋人物不断拓展和强化泛型编程的原因。