一些待解的疑问
想了想, 还真不知道拿什么题目起头。 这样, 从以前的文章开始好了。
为什么OO是有本质缺陷的?
namespace fields
{
struct name;
struct age;
struct code;
}
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
typedef map<fusion::pair<fields::name, std::string>, fusion::pair<fields::age, int>, fusion::pair<fields::code, char> > person;
使用时,我们这样使用:
person a_person;
at_key<name>(a_person) = s;
at_key<age>(a_person) = i;
at_key<code>(a_person) = ch;
事实上, 这是使用fusion,稍微更改一下形式, 就可以变成这样: a_person.p<name>, a_person.p<age>。如果碰见变化, 修改一下typedef即可。 而我操作person的代码,只要其本身的逻辑没有变化,就可以做到一字不改; 因为我可以通过获取map中所包含的类型定义携带的信息, 直接写一个统一化的过程, 进行所有操作。 而如果使用OO, 第一个可以想象的就是, 每一个倒腾数据的逻辑, 无论是从哪儿到哪儿, 我都得加上对该属性的操作。
这个最大的好处是,只要在本质上是相同的过程, 我们只用写一遍。 另一个好处是, 我们同时具有静态语言的全部优势: 比如没有定义和包含description的时候, 无论你是at_key<description>,还是a_person.p<description>,根本就不会通过, 这样在非常大量的这种工作, 比起Dictionary和动态语言, 我们就可以避免大量的失误。
我想, 这个问题不能简单的用“很少有人用”来回答,因为它是结果。 首先它是方便的,而且方法名、属性名这种给人使用的死标记没有的缺陷它也没有。 那么我认为,没人用更多的仅仅是因为, C++和另外那些支持这种非OO范式的静态语言,其它地方太烂,是首先否定了语言上的选择, 所以也就没人在实体上使用这种设计和实现的方式。
当然使用Dictionary就痛快多了, 不过强类型带来的保障没了,这是不是缺陷呢?还可以使用反射完成相同的功能, 然后付出性能, 在我看来,这个性能就是缺陷的证明; 比如: 数据源是数据库, 那么有的ORM就用反射完成类似的工作, 但ORM的存在,反而证明了需求的存在。而且在ORM覆盖范围以外的数据复制和转移呢? 性能问题, 我们可以通过Emit来解决, 但Emit不是适合于所有使用情景; 而且, 我们就必须编写和调试大量的Emit代码, 额外的设施的使用和多付出的工作量, 也是缺陷的证明之一。
毕竟, 这些信息本来就是运行前已知的, 而且他们是有规律的, 也就是可以通过某种形式在运行前处理的, 同时可以通过合理表达自动化的。某人嘴里的“孟老头”对这个事情有他自己的理解, 现在就看某人的啦: 这是不是OO的缺陷?
为什么OO是有本质缺陷的?
这篇文章中的疑问首先有这么一点: 静态语言中,我们如何能在改变一个系统内部接口的时候(注意, 不是对外发布的, 所以没有不能更改的问题), 只更改一处就解决问题? 比如最简单的, 一个类, 有Name属性, 是string的, 它对应某一个数据文件里的类似于表中一列的信息。 改变数据文件的结构,新添加了一个叫做Description的记录信息, 一个内部实体也增加了这个属性,我如何做到不修改从数据文件中读取, 和写入数据文件的代码呢?
毕竟, 这两个属性对这个数据文件的读写, 是没有什么差别的。举一个对比的例子, 在C++中, 我可以这样:
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/ExpandedBlockStart.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/ExpandedBlockEnd.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
使用时,我们这样使用:
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
事实上, 这是使用fusion,稍微更改一下形式, 就可以变成这样: a_person.p<name>, a_person.p<age>。如果碰见变化, 修改一下typedef即可。 而我操作person的代码,只要其本身的逻辑没有变化,就可以做到一字不改; 因为我可以通过获取map中所包含的类型定义携带的信息, 直接写一个统一化的过程, 进行所有操作。 而如果使用OO, 第一个可以想象的就是, 每一个倒腾数据的逻辑, 无论是从哪儿到哪儿, 我都得加上对该属性的操作。
这个最大的好处是,只要在本质上是相同的过程, 我们只用写一遍。 另一个好处是, 我们同时具有静态语言的全部优势: 比如没有定义和包含description的时候, 无论你是at_key<description>,还是a_person.p<description>,根本就不会通过, 这样在非常大量的这种工作, 比起Dictionary和动态语言, 我们就可以避免大量的失误。
我想, 这个问题不能简单的用“很少有人用”来回答,因为它是结果。 首先它是方便的,而且方法名、属性名这种给人使用的死标记没有的缺陷它也没有。 那么我认为,没人用更多的仅仅是因为, C++和另外那些支持这种非OO范式的静态语言,其它地方太烂,是首先否定了语言上的选择, 所以也就没人在实体上使用这种设计和实现的方式。
当然使用Dictionary就痛快多了, 不过强类型带来的保障没了,这是不是缺陷呢?还可以使用反射完成相同的功能, 然后付出性能, 在我看来,这个性能就是缺陷的证明; 比如: 数据源是数据库, 那么有的ORM就用反射完成类似的工作, 但ORM的存在,反而证明了需求的存在。而且在ORM覆盖范围以外的数据复制和转移呢? 性能问题, 我们可以通过Emit来解决, 但Emit不是适合于所有使用情景; 而且, 我们就必须编写和调试大量的Emit代码, 额外的设施的使用和多付出的工作量, 也是缺陷的证明之一。
毕竟, 这些信息本来就是运行前已知的, 而且他们是有规律的, 也就是可以通过某种形式在运行前处理的, 同时可以通过合理表达自动化的。某人嘴里的“孟老头”对这个事情有他自己的理解, 现在就看某人的啦: 这是不是OO的缺陷?