当然，各位看官又想到了，面向对象也不灵了，代码太多了，类太多了，又需要一种新的方法解决问题啦。不好意思，确实想说这句话。
自己回想，还是函数太多，还需要封装。阅读人家DELPHI源代码，人家用了一个新关键字，叫属性。这个属性有两种，一种是事件，我理解它是一种切入式编程，一种是正宗的属性。原来，人家用属性隐藏了函数。一个属性，可以有读的函数，也可以有写的函数。我过去是暴露了两个函数，人家只用了一个简单的属性就搞定，把函数都藏起来了。代码简单多了，调用也简单多了，容易理解多了，自己阅读代码也不需要关注那么多函数了，代码之间的关系关联性也更容易可见了。看来，还是需要继续多写代码，不多写代码，就遇不到问题，不多写代码，就琢磨不透现在这些技术到底是解决什么问题的，就无法深刻理解现在这些技术的精妙之处。还要继续多写代码，多琢磨代码。谁理解不透，就说明谁写的代码还是少。
??真是奇怪，面向函数，面向对象，面向组件，居然这样?每次都是增加一点点新的东西，就换个名字?就这么简单?但确实挺管用，解决了自己头疼的代码多的问题。代码一多，脑子就不够使，就不容易阅读理解，不容易下手修改，当然改了也是不知道能不能稳定(能稳定才怪，自己都看不懂代码，还想稳定?)
从面向函数，面向对象，面向组件，发现自己的代码被越封装越高了。就如同过去写程序，我们需要调用各种WINDOWS API，最后DELPHI把API封装成各个类库，有的更封装成了组件，如ADO组件和IP组件，就简单多了。写代码快多了。
但是，还有人不满足(当然也包括我)。大家不知道有没有这样的感受，组件拖拽，确实开发进度比过去是快了许多，但是现在的组件是越做越复杂，N多的属性，N多的方法，N多的事件，我要干某个工作，我不知道哪几个属性互相配合才能有效达到目的，一拉开属性查看器，看见滚动条和折叠起来的更多的属性配置就头大，心想怎么现在的东西这么复杂。
没办法，吃了馒头还要吃蛋糕，人的欲望是无穷的，这都还嫌不好。心想，如果我做某件事，传几个参数，OK，就能达到我的效果那该多好。别让我再配置这个属性那个属性，让我调用这个方法那个事件的。
看来，需求越来越复杂了，代码规模越来越大了，程序员必须加快工作效率才能应付的上，现在组件变的越来越复杂，程序员的编写代码速度与客户的变化速度不匹配了，唯有封装的更高。一个函数就搞定的。
嗯。面向服务出现了，一个函数就搞定，内部组件的属性如何改变，方法如何调用，那是组件内部的事情了。
文章来源于领测软件测试网 https://www.ltesting.net/
