容忍模棱两可是一件正确的事情吗? 我时常问自己,很遗憾我的人生追求的并非是一种意境.对这个广阔无垠的世界的无知让我感到困惑,焦虑,茫然,我内心充斥着对真理的渴望,探究,隽永,借由对世界的了解来消除无知带来的恐惧,所以我必须要在生命结束之前做很多本没有必要的事情来讨好自己,这样有意思吗? ...这个问题留给我人生结束时做最后一次自省吧.
在数年的java编程经验中,面向对象和泛型好像密不可分,都是为了实现多态,那通过继承实现和泛型各自的能力边界在什么地方呢?
最近在尝鲜c++,首先打算用c++来写一套类框架集,首当其冲被实现的是数组,内存里一段连续的数据结构.当时我就遇到一个问题,高级数组的类型是要用泛型T来实现还是用面向对象的base model继承来实现:
//这样的区别
ArrayList<T>
ArrayList<Object>
在这个数据实现的内部,无论是T还是Object都是一个通用的符号,用于API的封装,期初我想让数据的灵活度更好,并且元素更纯净,我选择了'T'泛型这个方案,很顺利的封装好了数组,想着这样既可以设置数组类型为基础数据类型,也可以设置为对象,结果到了测试阶段,发现一个问题,这个数组不能按照我的想法兼容对象和基础数据类型,为啥呢?看一下下面这个API:
//获取数组元素下标
int indexOf(Object *node) {
Object *ptr = instance;
for (int i = 0; i < current_node_sum; ++i) {
//这里直接对比了指针的地址
if (node == ptr) {
return i;
}
ptr++;
}
return -1;
}
很普通的一个API,获取数据元素下标,通过递归指针的方式遍历了数组,然后比对遍历的元素是不是形参上的元素,那么问题来了,怎么比? java中是equals方法搞定的一切,c++呢? 对比指针地址,判断元素在内存中是否是同一个地址,来确定是否是同一个元素.好,那么问题又来了,看下面的代码片段:
c++对比两个不同种类的指针地址,直接编译报错,不符合c++规范,我们这里用泛型绕过了编译器检测,这里如果数组是包装类型,形参传入的是基本类型,那怎么办?就像下面这种情况:
ArrayList<Integer> list;
list.add(Integer(1));
//这里indexOf方法直接传了一个1进去
list.indexOf(1);
这样的indexOf方法因为比较了两个不同类型的指针地址,直接报错,没招.
除非两个条件满足一个:
1:不允许数组使用基本数据类型
2:数组元素拥有equals方法,杜绝对比不同类型指针的风险
然而无论是哪个条件都只有一个办法能解决这个问题,没错,就是通过继承base model的思路去实现高级数组.
这就是为什么java的类框架集里要有Object作为顶层超类,一方面出于双亲委托的加载模式的控制,另一方面就是和本文分析的原因一样了,JDK隐藏指针的实现,但是究竟怎么对比java中两个对象呢?没错,就是通过比对两个Object对象的指针地址,也就是Object 中this指针的地址:
仿造JDK我自己封装了一个基类Object,实现了equals方法,并将高级数组改造成元素继承自Object的实现方式
完美解决了这个问题.
Object.equals方法
bool Object::equals(Object &obj) {
return (this->self == obj.self);
}
改造后的ArrayList.indexOf方法
//获取数组元素下标
int indexOf(Object node) {
Object *ptr = instance;
for (int i = 0; i < current_node_sum; ++i) {
if (node.equals(*ptr)) {
return i;
}
ptr++;
}
return -1;
}
网友评论