我们的开发团队依然没有彻底的用好OO的开发模式，依然在用非面向对象的思想来开发出好像是面向对象的程序，也即类OO,但是没有做到彻底的OO,但是要在团队里扭转思想不是一件可以立刻做立刻出现效果的事情，但是OO的确有他的好处，那么对于OO,能够给我们带来什么好处呢？下面是我的想法，用文字表达一下，加强自己的理解，彻底的OO带来的好处就是能够比较符合人类的和现实世界的思考方式，所以当我们要去学习理解一个系统时，可以通过OO模型来比较快速建立一个初步概念，然后根据这个概念为纲一步步深入学习系统，如果严格符合OO设计模式的系统，我们可以利用UML反向工具根据代码来快速生成静态类图，从类图上了解系统中个个类之间的关系，好帮助我们进一步的学习系统中大量的代码，其实这里还隐含了另外一个问题，就是：我们在设计、实现系统中，应该是会产生一些辅助类的，这些辅助类可能跟系统的业务没有直接的关系，仅仅是我们在系统设计过程中为了达到某种目的（如松耦合、易扩展）而加进去的，这些类其实也会影响我们对业务的理解，至少在刚刚接触、学习一个系统时是会有影响的，但是，如果我们的设计过程如果能够严格、而且适当的遵循面向对象的设计规则，而且明确的利用设计模式，而且学习了解系统的人又是按照这些思路去了解展开学习的，那么就可以降低阻碍性，依然能够起到引领理解的作用，所以在敏捷软件开发方法论中，不提倡过度的花时间在制作文档上，而是提倡代码既是文档，因为一个思路清晰、关系良好的设计通过最终代码反向生成的UML已经是最好的文档了，而某一些太过于细节的实现算法和逻辑在任何时候都是需要查看代码进行确认和了解的，当然面向对象能够支持良好的分层解耦也是其中的一个好处，不过我认为这种解耦并非一定要通过OO来实现了，面向过程也一样可以做到的，就像在博客园里的讨论的一样，“接口其实仅仅是大家订好的一个契约”，不用面向对象的技术也一样能够实现这个契约，用函数、方法也可以，只是如果用面向对象力量的interface和abstract class更加符合面向对象设计的原则和模式，如果参与的人都熟悉这方面的就能够增进理解和加强沟通而已，所以非面向对象并不能成为强耦合出现时的接口，嘿，其实这个问题在我刚接触OO思想的时候就困扰过我，最后才悟通了过来，所以程序设计应该有一个前提：就是我们的设计方案是为了降低理解的成本的，如果发现设计方案需要花费太多的脑汁来理解的时候就要考录一下是否已经过度设计了，当然这里的前提是：你设计的是应用系统，而不是通用的框架或者控件，框架和控件一般都必须具有通用性，所以为了低耦合、易扩展有必要加入复杂一点的设计来达到目的，另外从敏捷的开发方法论来说，提倡不要过度的猜测可能产生的变化，而是有变化的时候通过重构的方式来实现，但是：重构毕竟需要时间重写代码啊，这个问题还依然困扰我，是否可以借助一些自动化的代码生成工具呢？就像是ORM,或者codesmith等工具，我虽然没有对这些范畴有深入的了解，但是，对于设计方案改变的重构，使用ORM或者codesmith现在还是不看好，也许他们只是应对数据库结构改变方面有用处，但是对于比如加了一个适配器或者是工厂的这种设计方案改变应该还是应付不来，嘿，在公司碰到最多的是：为一个表征加以个字段并显示到变现成，这种必须贯穿真个系统分层的需求变化，有没有什么比较好的方法来处理这种简单的重复性工作呢？有待我慢慢学来

其实OO也有坏处啊，性能是个问题啊，然后团队成员的学习也是个问题啊，不过现在反而是一些年轻的程序员有这样的思路，因为现在接触到的培训、教学等都是用OO的思想教的，所以后面这个也不是太大的问题了。

也不知道自己的想法对不，反正先写下来先，如果日后有更正确的认识，也能体现出自己进步来了。