面向对象带来方便的同时亦带来很多的问题。类的继承在扩展的同时也违背了封装的原则，基类的内容通过子类的继承被暴露出来。对象的封装其实破坏了一种关联关系的整体性，同时过多的get和set方法也实在是浪费时间和增加代价。而方法的多态型表述所带来的可能的混乱不比其带来的方便少多少。因此，在C++以后的OO语言里，不论是Java还是C#，包括他们的编译器，都在这些方面做了一些改进。
在面向对象的开发过程中，是不是一定要坚持“万物皆对象”也是值得商榷的。一个简单的例子，如果我要一次更新10000条记录的某个子段。用SQL语句的话，只要一句update就可以了。但是在“面向对象”的思想下，我们不得不建立10000个实体，取得他们的所有值，再依次更改他们的属性，最后一个个保存到数据库中。即使不考虑10000次数据库连结的耗费，用这么多个实体这么大的代价究竟能换来什么呢。仅仅是代码的可读性、分层性和可维护性好一点么？
基于数据库的面向对象开发中，如何把实体-关系的建模语言反映到关系型数据库中、如何把关系型数据库的结构映射到对象中，都是目前比较头痛的问题。多表连接的查询处理、实体之间关系的OO表示，很多时候只能客制化的处理。在遵守OO的原则下，却不得不做出违反OO的结果，是技术的问题还是设计思想的问题呢？
在面向对象的开发过程中，是不是一定要坚持“万物皆对象”也是值得商榷的。一个简单的例子，如果我要一次更新10000条记录的某个子段。用SQL语句的话，只要一句update就可以了。但是在“面向对象”的思想下，我们不得不建立10000个实体，取得他们的所有值，再依次更改他们的属性，最后一个个保存到数据库中。即使不考虑10000次数据库连结的耗费，用这么多个实体这么大的代价究竟能换来什么呢。仅仅是代码的可读性、分层性和可维护性好一点么？
基于数据库的面向对象开发中，如何把实体-关系的建模语言反映到关系型数据库中、如何把关系型数据库的结构映射到对象中，都是目前比较头痛的问题。多表连接的查询处理、实体之间关系的OO表示，很多时候只能客制化的处理。在遵守OO的原则下，却不得不做出违反OO的结果，是技术的问题还是设计思想的问题呢？
