敲响OO时代的丧钟！——DJ对于数据持久化的支持(3)

OOer们总是喜欢吹嘘“XX重用”，谎言说上一千遍，就成了真理。
对于这种赤裸裸的谎言，简单的面向过程案例就可以将其华丽的轰至渣。

还是解码器的案例，标准的输入输出接口，可置换的解码芯片。

OO设计2

class device
{
	Input();;
	Output();;
	virtual Decode();;
}

class device1 : device
{
	override Decode();;
}

class device2 : device
{
	override Decode();;
}

usage:
// 解码方案1
device d = new device1();;
d.Input();;
d.Decode();;
d.Output();;

// 解码方案2
device d = new device2();;
d.Input();;
d.Decode();;
d.Output();;

使用继承及接口技术，重用了Input、Output的实现及Decode的接口，看起来好象很伟大

设计3 看看面向过程

Input();;
Output();;
Decode1();;
Decode2();;

usage:

// 解码方案1
Input();;
Output();;
Decode1();;

// 解码方案2
Input();;
Output();;
Decode2();;

设计2和设计3基本上是等价的，设计1则最愚蠢。在面向过程的设计理念中，Once and Only Once 本来就是最天经地义的事情，同一件事不会去做两遍，OO的继承及接口机制不过是使OOer们能够避免愚蠢设计回归到正常设计而已，犯不着整天挂着“重用”的美名自娱自乐。

OO设计2

class device
{
	Input();;
	Output();;
	virtual Decode();;

                    process();{
                          input();;
                          decode();;
                           output();;
                    }
}

class device1 : device
{
	override Decode();;
}

class device2 : device
{
	override Decode();;
}

usage: 
// 解码方案1 
device d = new device1();; 
d.process();; 

// 解码方案2 
device d = new device2();; 
d.process();; 

OOP/AD basic

本文是为了配合庄子的论文，做一些OO的基础知识普及工作。
当然，即使是OO基础知识，我也不一定有足够的资格来普及，主要目的还是为了相互学习，共同进步。因此，为了便于读者找出漏洞，进行批评和抨击，帮助我进步，我尽量使用朴实无华，简单易懂的语言。用咱老百姓自己的话，讲述老百姓自己的故事。
为了突出重点，加强效果，文中不免矫枉过正，提出一些片面极端的看法。
为了方便起见，我也把Procedure Oriented称为PO。

1．代码重用
评价一门语言的重要标准之一，就是代码重用程度。PO的代码重用主要有两种方式：(1) 模块重用 Module Reuse (2) 模板重用Template Reuse

模块重用。比如，一个 a 模块，b调用a，c也调用a。这时候，a就是重用的。这种情况比较简单，PO已经做得非常好了，OO这方面没有什么太大的超越。

模板重用。一个处理流程的整个步骤都是固定的，就是其中一些部分是变化的。比如，在那个Design Pattern帖子里面。
http://forum.iteye.com/viewtopic.php?p=82944
那个排序的例子里面，sort算法是重用的，comparator是变化的。这个时候，sort就是一个模板template，comparator属于模板template中的变量。
OO在模板重用这个方面具有超越PO的语法优势。PO一般用Callback Function Pointer实现模板重用，而OO的Class内置支持this指针，具有了携带额外信息的能力。

2．OOP只是一种语法现象
PO如果要达到OO的效果，则需要用Struct + callback function pointer来模拟实现。C的语法记不清楚了，下面的代码就是一个示意。

struct  Comparator{
   void * info;
   int (*compare); (Runnable *  this,  Record a, Record b);;  // compare is a function pointer
   // 注：具体的OO实现中，为了处理继承的多态，
   //虚函数指针不是直接放在这里，而是放在一个虚函数表
};

….

void sort(Record[] records，Comparator * comparator);{ 
        for(int i =….);{ 
                for(int j=….);{ 
                        if(comparator->compare(comparator, records[i] > records[j]); > 0);
                                // swap records[i] and records[j] 
                } 
        } 
} 

如果要实现ReverseComparator，那么相当麻烦。

int reverseCompare(Runnable *  this,  Record a, Record b);{
     Comparator* originalComparator = (Comparator *);this->info;

     return – originalComparator->compare(this, a, b);;
}

….
Comparator field1Comparator;
… set up field1Comparator

Comparator reverseComparator;
reverseComparator.info = &field1Comparator;
reverseComparator.compare = reverseCompare;  // function pointer

sort(records, &reverseComparator);; // reverse order

可以看到，PO实现高级的模板重用，不是不能做到，而是做起来非常麻烦。而OO语法内在就支持这种高级的模板重用。另外，OO语法的继承，对代码重用也有良好的效果，不过，目前继承好像有成为反模式的趋势，我就不多说了。怎么方便怎么用，代码简单，才是硬道理。

我在网上找到了《Modern C++ Design》繁体中文版的前四章PDF文件。果然不出我所料，Loki的设计思路与我的随后将会介绍的自己的设计实现，实有异曲同工之妙。对于C++的熟悉程度超过Java的某同学，可以先去看看这本书，如果能够同意书中的观点，再来与我讨论，相信会得到更多的收获。

大家都应该承认，ADT是OO的根。数据与操作的封装是一切OO思想的基础，也是所有OO信奉者从来没有怀疑的“前提”！

这句话特别关键，让我再仔细分析给大家看看：ADT＝抽象数据类型。就是封装了操作和数据的一种用户自定义数据类型。
1、如果仅仅是ADT，那么相近的用户自定义数据类型就无法重用，因此出现了一个数据类型的重用需求；
2、因为ADT封装了对于数据的操作，对于A类数据的操作，就无法被B类数据重用，因此出现了一个ADT内部代码的重用需求；
3、因为对于ADT的操作是借助ADT的外部界面执行的，也就是说，对于接近但是不同的类型的操作，必须写出不同的代码，因此出现了对于操作ADT的代码的重用需求。
这样的分裂的三个需求，在随后的OO的发展历史中，分别被两种方法来初步满足。第一、第二种需求，被继承这样的技术来试图满足；第三种技术被泛型类试图满足。这两个技术满足了三种重用的需求了吗？没有！不但没有满足，而且还带来的诸多麻烦的问题，更在分别满足三种需求的时候，起了冲突。（前面已经讨论过的内容，可以回头再看一看，我将来再改写这篇文章的时候，会将封装 VS. 重用性的分析，作为一根主线贯穿OO分析的始终，现在就不重新组织结构了。）
由于封装与重用性之间，存在着本质性的冲突，

可以这么写，就体会出OO语法的优势。

OO设计2

class device
{
	Input();;
	Output();;
	virtual Decode();;

                    process();{
                          input();;
                          decode();;
                           output();;
                    }
}

class device1 : device
{
	override Decode();;
}

class device2 : device
{
	override Decode();;
}

usage: 
// 解码方案1 
device d = new device1();; 
d.process();; 

// 解码方案2 
device d = new device2();; 
d.process();; 

// 解码方案1 
Input();; 
Output();; 
Decode1();; 

// 解码方案2 
Input();; 
Output();;
Decode2();; 

难度这client的重复代码便不算重复代码了么？
若是有人将这解码器的程序写至你这样，便素该杀亚。

单从语法上看好象很有道理，只不过device提供的Input和Output接口是给外部client使用的，不是给device用process来自娱自乐。

无论什么P最终都可以归结为一种语法现象，但语法现象只是外在的技巧性的价值，现在的讨论太过重视技巧性的东西，反而忽略了内在的更高层面的价值。

usage: 

client code
process(Device d);{
   d.input();;
   d.decode();;
   d.output();;
}

// 解码方案1 
device d = new device1();; 
process(d);;

// 解码方案2 
device d = new device2();; 
process(d);;

OO设计的价值并不在于所谓的“复用”，无论如何设计，最好的结果就是和过程设计等价。

模块重用。比如，一个 a 模块，b调用a，c也调用a。这时候，a就是重用的。这种情况比较简单，PO已经做得非常好了，OO这方面没有什么太大的超越。
模板重用。一个处理流程的整个步骤都是固定的，就是其中一些部分是变化的。比如，在那个Design Pattern帖子里面。
http://forum.iteye.com/viewtopic.php?p=82944
那个排序的例子里面，sort算法是重用的，comparator是变化的。这个时候，sort就是一个模板template，comparator属于模板template中的变量。
OO在模板重用这个方面具有超越PO的语法优势。PO一般用Callback Function Pointer实现模板重用，而OO的Class内置支持this指针，具有了携带额外信息的能力。

OO设计2

class device
{
	Input();;
	Output();;
	virtual Decode();;
}

class device1 : device
{
	override Decode();;
}

class device2 : device
{
	override Decode();;
}

usage:
// 解码方案1
device d = new device1();;
d.Input();;
d.Decode();;
d.Output();;

// 解码方案2
device d = new device2();;
d.Input();;
d.Decode();;
d.Output();;

使用继承及接口技术，重用了Input、Output的实现及Decode的接口，看起来好象很伟大

现在我们有这样一个需求，对于得到的ArryaList，能够一一调用里面的对象的add(int a)方法，当然了，只要这个ArrayList里的对象都是X或者X的子类就行了。我们可以写出这样的代码：
。。。
全文参看http://spaces.msn.com/members/zbw25/PersonalSpace.aspx?_c01_blogpart=blogmgmt&_c=blogpart

这里问一个题外话，如果java有c++的模板机制的话，客户端的调用就不会调用两次，根据模板方法来写（不好意思，c++不熟悉不知道什么写），不过可以肯定是可以实现的，而java里面有泛型功能，但好像不能解决这个问题（客户端重复调用的问题,使用泛型，好像只有collection那些类可以使用。