面向行为编程！继面向对象的新的软件开发模式

对！面向行为的核心思想就是把参数和返回值一并忽略，只需要一个行为名称就可以直接调用了。当然，一个行为所需要的数据不可能凭空产生，需要调用这个行为的上一个行为进行注入。而负责这个模块的程序员只需要关注模块的实现，从而实现低耦合。在团队开发中，各个模块当然是由不同的人去完成的。

谢谢！

当然啊，实现的时候难免会出现一些很空洞或者内聚性很低的行为，但可以在后期维护的时候进行分包，优化。所以软件的事先设计和后期维护也很重要嘛

我不是来损LZ的,只不过你回到了面向过程还沾沾自喜

不是我泼冷水，之前公司一个银行项目有个老人自称：谁能改我代码，谁就是牛逼的人。

他用的就是你这种执行方式，用起来、改起来、debug起来都是超级、超级麻烦。。。。。。。。。。

这个和用反射获取相应的实现类，在各个实现类之间用一个通用的上下文来传递数据的思想是一样的嘛

能不能不要用这样的标题，误导大家啊

一般软件开发都有3个角色，接口（方法或行为）的定义者，接口的实现者，接口的调用者，有的是时候3个角色是同一人。楼主的方法可以简化接口定义者的工作量，但并不能减少其他两个角色的工作量，调用者和实现者也没有减少耦合。就拿用户登录的例子来说，假如以后增加管理员登录，要多传一个参数-验证码。行为调用和实现的代码都要修改做相应的判断。本来应该是接口定义者的工作（应该在设计阶段考虑好的事情），分给了调用者和实现者，让他们俩自己商量着办吧。

这种方式肯定会增加调试和维护的困难。以后换了一拨新程序员，不仔细读代码很难调试程序。yangm1203已经给出了他的答案，如果他们项目中的那个老人是个架构师（接口定义者）的话，真是够懒够聪明！

另外判断一个架构，一种编程思想好坏的一个重要标准就是成本。成本包括使用技术的难易程度（招个高级程序员还是初级程序员成本肯定不一样），代码量（10月和2个月也不一样），调试和维护的工作量。

被标题晃了一下，lz说的只是开发小技巧、小方法而已，离开发模式还比较远吧

我猜楼主想说的是鸭子型