对象？过程？折中？

用java开发一年了，现在算开始独立设计一些功能了。从一年前不知道什么是多态的小白，到现在开始参加第二个项目的开发，自认为对面向对象设计已经知道了点皮毛了。可能我还是以一种近乎于崇拜的心态来面对面向对象设计和java开发，所以迷恋于接口，对象封装，代理等等一系列概念实在不怕别人笑话。

我一直在追求低耦合的设计。功能模块间尽量降低直接引用，功能模块对外部尽通过接口交互。每个类和方法的功能尽量简单，接口方法的参数和返回值简单，方法功能单一容易做单元测试。功能类间多使用代理而不是继承，一方面弥补java没有多重继承的缺陷，同时提高设计的灵活性和扩展性，子功能模块的小颗粒度可以最大限度的提高代码的重用，做到高级功能模块是基础功能模块的组合。

读过几千行代码的一个方法，充斥着分支语句和零散的注释，看过一万多行代码却没几行注释的类后我发誓自己不能这样设计。我并不追求所谓1：1的代码和注释，重构那本书里好像讲过，凡是感觉需要注释的代码就说明这里的代码有可能需要修改了。好的代码可以自己说名流程，不过这可能需要规范的命名。也许有人说JDK中的代码注释那么丰富，当然它是工具包，是给全世界的开发者看得，我们写的代码更多的是要给自己看，对外的接口方法注释可以写的详尽一些。再说我还是很少看到JDK代码有在方法体内部写注释的，更多的说明代码用途的还是代码本身。

一些前辈们认为，过于对象化和设计有些过分，他们往往认为一个方法可以搞定的问题为什么要再提出一个接口来？这就又回到对象与过程的老生常谈上了。面向对象确实存在不完美的地方，过多的对象的生成会造成内存消耗的膨胀，即使是临时对象，在大数据量的操作时仍然不能十分依赖java内存回收。类装载，对象初始化都是性能的消耗，同时方法调用也有性能的消耗，虽然这在一般情况下几乎可以忽略，但是频繁的调用可能使这样的消耗变得明显。前辈们也不大赞同为将来的扩展预留接口，认为这属于过分设计。前辈们的意见也是有道理的，以他们的经验也许能很敏感的发现怎样的设计会造成资源的消耗，一个是项目的资源，包括人力和时间；另一个就是程序运行时的资源。

不过，也许我道行尚浅，我还是认为在设计时过多地考虑性能问题也是没有必要的，有书里管这个叫作“2000年综合症”。面向对象本身就是更符合人们思维方式的设计方法，我觉得将不同的需求和任务抽象成对象是更简洁的建模方法。当然，一个设计总不会尽善尽美，在编码和维护阶段不断的重构以改善设计和提高性能都是必要的。而维护阶段的工作量也取决于最初的设计，相对较好的设计结构和足够的测试案例会为日后的维护降低很大的成本。

我觉得设计时也需要适当考虑要面向测试，毕竟单元测试是现代软件开发中必不可少的一环。细颗粒度的模块，功能单纯的方法是有利于单元测试的，虽然单元测试可能迫害一些对象的封装性，不过总体来说这与面向对象的设计并不相勃。

面向对象和面向过程的设计思路是有很大的冲突，不过为了提高软件质量，我承认最终他们是需要互相借鉴的（虽然我痴迷于对象）。完全的追求一种思路其实并不难，毕竟我们身边有那么多教科书都在教我们这些。但是困难的是在应用中如何在二者间寻求一个折中，再不失结构的前提下最大的提升性能，以达到软件质量的总体提升。

自己一点感想，谈得很肤浅，请前辈们指教。