面向对象vs基于对象
看到了一种说法，很多所谓面向对象开发只不过是基于对象的开发。反思自身，发觉一针见血。
我们所谓的面向对象，实际上只不过封装了业务对象，分出了层次，提供了接口。虽然在设计和实现的时候使用到了面向对象的封装，但现在看来还算不上真正的面向对象，只能算是基于对象而已。
面向对象的原则并没有符合。面向对象的优势也没有发挥，反而感觉一个小变化就牵扯到多层的变动，麻烦。就好比去年的项目，数据库采用ORACLE，实际本身对ORACLE并不熟悉，只经过不到一周的学习，就上马了。结果只不过将ORACLE当成MSSQL使用。ORACLE的强大不但没有体现（到现在也没有搞明白），反而失去了MSSQL的好的经验。得不偿失。
不过，如何才算真正的面向对象呢？想了想一个好的面向对象的实践，应该是达到最大限度的软件复用，并且可以快速适应不断变化的需求，而对已有的部分影响最小。
这不是一蹴而就的事情，如果想真正的用项目来实践的话，正确的步骤也许应该是：
首先采用本身较熟悉的开发方法（基于对象或是面向过程）满足业务需求。这一步很关键，只有有了这样一个原型才可以验证对需求的满足程度。个人感觉直接面向对象会陷入设计过度，并且在前期耗费大量的精力。更重要的是使用不熟悉的技术会带来风险，得不偿失。
然后逐渐的将采用真正的面向对象的方法将现有的原型进行重构。目的是提高性能，灵活性，扩展性，可复用性等等，这是一个长期的不断迭代的过程。可以参看经典的《重构-改善代码质量》。
最后一步是架构的提炼。将系统中的可以外部复用的部分提炼出来形成一个可以复用的框架架构。有了它，以后的开发相会事半功倍。此步骤将会用到重构和设计模式。整个的过程除了第一步和面向对象无大关系外，后两步则完全的面向对象的思想。
在此之前总是希望先有一个设计良好的架构，一直这样不断的学习和进行实践。结果却不尽人意。经验说明这样做确实有些本末倒置。正如模式的使用一样，在动机不明确的情况下盲目的套用模式是没有意义的。
每一个开发人员的脑袋中有一些非常美妙的创意，这些创意没有实现的一个原因就是，太过关注细节。对于面向对象还是基于对象开发，对于实现需求，完成项目的初期阶段，真的无所谓。当需要考虑提高开发和维护效率的时候，面向对象就成了很不错的选择。