一些待解的疑问
想了想， 还真不知道拿什么题目起头。 这样， 从以前的文章开始好了。
为什么OO是有本质缺陷的？
namespace fields
{
struct name;
struct age;
struct code;
}
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++中， 我可以这样：
namespace fields{
struct name; struct age; struct code;}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的缺陷？
