编程便笺：过度消费的对象

　　这篇文章的正文部分写好有一段时间了，根据现在的想法，又在前面加了一些想法。面向对象是很好的方法，有些方面其实在被误用，有些方面在新的需求面前似乎需要作调整。

1、接口协议保证了服务对象的分层和规范,但限制了消费端的独立性。

　　很多的时候我们把消费端设计成服务的调用着,而在企业应用设计中,有时
把把消费端设计成信息提供者会更有效,只是根据服务指令提供相应的信息,而对于服务接口和协议基本无知.这个时候通过服务端和消费端的约
定,可能比通过协议更有效率.

2、对象特性保证了对象的结构层次特性,但组合特性相对较弱.

　　对象编程要求组合是封闭的,而规则编程等则要求组合是开放的,可重组的.对这些方面的编程,并不是说对象编程不能实现,而是实现起来有些勉强.

3、语言编程缺乏由果溯因的能力，计算语义、逻辑语义、控制及规则语义缺乏有效的整合。

　　缺乏对需求进行整理归类的能力.编码往往反映的是结果, 而原因在编码中体现不出, 这样很容易使得编码与需求脱节,而在需求考虑时,会太顾及实现方面的因数,而不是需求本身,需求被阉割。规则零碎化，不能以统一的方式体现， 商业模式和业务规则的调整，往往意味着新的开发。

4、代换方式偏重于值代换，其他方式缺乏简单有效。

　　过于强调计算能力,对于计算表达的表现能力则相对欠缺,语法简单但过于单调死板,词计算能力缺乏，对于规则以及相关的职责分工缺乏有效的表现。

5、类对象的内存印象满足了性能的要求,但杂凑能力不强。

　　相当多的编程模式或多或少地受这方面的影响.

6、语言生态，...。

　　这方面就不展开了.

　　面向对象编程，是软件编程的重要方法，在许多人心理，也许就是唯一的方法。面向对象的编程方法，可以让我们很容易的把各种信息组合在一起，写出比较稳定、实用的程序，极大地提高了编程的效率。对象是如此好用，我们也对对象产生了依赖，甚至到了过度消费的地步。

　　我们在许多场合使用对象，而我们熟知的对象含义，还是适合于编程领域的，就更计算机语言一样，在编程中使用的对象概念，其实已经做了很多简化，而与实际工作中的需要已经有一段距离，也就是说，我们套用编程中对象概念，去描述需求时，已经不能体现本身事物的层次、细节甚至概况。以前的应用编程，更多地以程序员的角度设计系统，这样的不一致不是显得很突出，而在现在，当我们更多地站在业务角度上设计系统时，如果不能很好地区分这两者之间的区别，难免似是而非，产生误导。在需求分析和业务设计时，有时特意避开对象的概念，其实也不是想象中所认为不可行的，其实我们用合适语句和词汇去描述业务规则，可以显得更加简单和自然。而当我们把业务规则直接当成程序语句时，面向对象程序部分很大程度上成为由规则自动生成的后台驱动。

　　在企业应用系统设计时，规范化是最常见被提到的一个词，但说实话，很多的时候説的是规范业务，实际上是用软件的规则去摆平业务的规则，所以这样的规范，也就成了项目经理和软件公司的托词。在上面已经提到系统设计时应该面向软件而是面向业务，其实现在在设计一个系统时，基本不考虑软件和技术的限制，而是更关注于业务的实现，其实应该是可行。也就是说，我们按照想法，只要愿意，做一个有效率的实现，应该不是难事或者无法克服，所以在设计时更应该关注业务的本身，而不是软件的限制。作为好的项目经理，当看到需求描述时，在脑海里就有了基于程序的构思，但当我们强调面向业务设计时，这样的技能有时反而会影响需求的实现，因为这个时候是在搬需求，而不是在努力理解需求需求，及需求后面的业务意义。就如看书一样，只是在努力理解书的内容，而不是在跟书后面的人对话。

　　作为软件员，我们经常抱怨用户需求的变动，其实用户是不会无缘无故的去改变和调整需求，出现这种情况主要有下面几种原因：1)对需求的理解不彻底，也就是说实现的系统与需求有距离。软件不能反映需求，难道这样的调整是错的？2)业务本身有调整。软件是为业务服务的，业务有调整了，想想软件不调整会出现的状况。3)编程受拘于软件技术，这样的情况就不多说了。

　　在软件设计时，有时会过于关注程序的结构和编程的技巧，其实这样的关注很多是多余的，有时甚至是有害的。当我们需要经常关注软件和语言领域的各种观念，如类型、对象、模式等，而不是应用领域的各种观念，则说明我们采用的语言和平台与我们要实现的应用之间有很大的落差，以致于我们不能专心于业务问题。