|
锁定老帖子 主题：面向行为编程！继面向对象的新的软件开发模式
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-02-01
add2ws 写道 mefan 写道 看起来是面向接口又像鸭子原则，你说的“面向行为”不是面向接口的概念吗？
两个问题： 1.boolean success = (Boolean) resultSet.get("success"); 我怎么知道有"success"这个东西？我怎么知道返回一定是bool? 2.和 pub Obj login(Obj... args)有什么区别 1.success是在事先的设计文档里说明的啊。 2.方法（接口）的传参和返回结果都是事先定义好的，而且只能有一个返回值。而行为的参数调用类似spring的ioc原则，将本身对参数的依赖反转给上级行为。而且行为的返回结果可以有多个，而不只一个 既然事先的设计文档都知道输入输出，你为什么还要将它还原成弱类型语言呢 为了ioc....若是为了行为抽象化，你应该这样写 @Act("login","other"...) pub Obj func(Obj... args) 这样return 一个仿元组类，不是更安全 也许php之类语言更合适你 |
| 返回顶楼 | |
|
发表时间：2011-02-02
最后修改：2011-02-02
mefan 写道 1.success是在事先的设计文档里说明的啊。 2.方法（接口）的传参和返回结果都是事先定义好的，而且只能有一个返回值。而行为的参数调用类似spring的ioc原则，将本身对参数的依赖反转给上级行为。而且行为的返回结果可以有多个，而不只一个 既然事先的设计文档都知道输入输出，你为什么还要将它还原成弱类型语言呢 为了ioc....若是为了行为抽象化，你应该这样写 @Act("login","other"...) pub Obj func(Obj... args) 这样return 一个仿元组类，不是更安全 也许php之类语言更合适你 文档只是用来参考和约定，因为它不会牵涉到代码。之所以用弱类型是因为设计时的不确定因素可能使参数类型在具体实现中会发生变化，比如说一开始定义成int型，但后来发现不够用，要换成long型，这样所有调用你这个接口（方法）的人必须都要去改，牵一发而动全身。所以说不如大家都先一率使用弱（Object）类型，然后按照文档的约定设计再在自己的实现里强制转回强类型，这样就能保证程序员不会因为接口的变动而使代码画红线而停滞任务了 |
| 返回顶楼 | |
|
发表时间：2011-02-02
add2ws 写道 zijan 写道 一般软件开发都有3个角色，接口（方法或行为）的定义者，接口的实现者，接口的调用者，有的是时候3个角色是同一人。楼主的方法可以简化接口定义者的工作量，但并不能减少其他两个角色的工作量，调用者和实现者也没有减少耦合。就拿用户登录的例子来说，假如以后增加管理员登录，要多传一个参数-验证码。行为调用和实现的代码都要修改做相应的判断。本来应该是接口定义者的工作（应该在设计阶段考虑好的事情），分给了调用者和实现者，让他们俩自己商量着办吧。
这种方式肯定会增加调试和维护的困难。以后换了一拨新程序员，不仔细读代码很难调试程序。yangm1203已经给出了他的答案，如果他们项目中的那个老人是个架构师（接口定义者）的话，真是够懒够聪明！ 另外判断一个架构，一种编程思想好坏的一个重要标准就是成本。成本包括使用技术的难易程度（招个高级程序员还是初级程序员成本肯定不一样），代码量（10月和2个月也不一样），调试和维护的工作量。 我的意思正是把接口（参数和返回值）在代码里隐藏起来，这样程序员在实现他的功能模块的时候就不会因为接口设计不当（缺少参数或返回值）而停滞任务。正如你刚才所说，假设多了一个验证码，按照传统的接口编程的话，不只是要改你自己的实现和接口了，因为别人可能已经在自己的模块里调用你的接口了，大家的代码都要改。但如果用行为来封装自己的模块，传入参数的更改根本不会影响到别人对你模块的调用，大家不需要改代码，只要在设计文档里把行为的所需参数做相应的修改即可了 我基本同意你说的，改变接口可以不影响原有模块的调用。但是会对设计文档过分依赖，实际开发中很难做到文档和代码的一致，尤其是上百人的大项目。必须设专人管理检查文档，只要有一点文档没及时更新，扯皮的事情就在所难免了。这种开发模式也许更适合小项目。你是否已经在项目中用到了这种开发模式？项目有多大？怎么协调行为的调用和实现的？调试程序是不是方便？另外对开发成本的影响有没有考虑，毕竟培训一个新人用一种新的开发模式需要一定时间。 |
| 返回顶楼 | |
|
发表时间：2011-02-02
我感觉很恶心，什么都一块煮
|
| 返回顶楼 | |
|
发表时间：2011-02-03
支持int->long 这种重构是应该是ide做的事情吧
非要避免这种重构的话，用泛型接口就好了 鸭子型其实不怎么适合静态语言，除了调用二进制文件库一类的才会有这种需求。 |
| 返回顶楼 | |
|
发表时间：2011-02-03
这种设计模式就有了.
它的根就是面向对象的思想 . 行为 -- > 对象 . 你自己创建的模式,达到更深的抽象,使代码解耦 |
| 返回顶楼 | |
|
发表时间：2011-02-03
faylai 写道 我感觉很恶心，什么都一块煮
这你就错了，我只是把参数的定义省略了而已，原来方法里参数怎么用，在行为里还是怎么用。并没有刻意去糅合任何东西 |
| 返回顶楼 | |
|
发表时间：2011-02-03
这种实现方式使业务接口非常不清晰，如果暴露为WebService，真不知道让外部怎么使用?得不偿失呀!
|
| 返回顶楼 | |
|
发表时间：2011-02-03
fjjiaboming 写道 这种设计模式就有了.
它的根就是面向对象的思想 . 行为 -- > 对象 . 你自己创建的模式,达到更深的抽象,使代码解耦 对！行为实质上也是对象！因为面向对象的核心思想就是“万物皆对象”，只要是能用语言表达出来的事物，都可以看作是对象，行为也是如此。但你敢说面向对象里没有面向过程东西在里面吗，程序的本质就是按代码一行一行按步骤按过程执行的，你的程序再怎么神也得按照严谨详细的过程去执行。关键是代码与我们关心的业务，与我们日常的思维习惯联系是否紧密，我们是把注意力放在代码的执行过程上还是对象上。但我认为面向对象的思想在涉及到一些参数结果都不稳定的业务处理时仍显不足，所以才出现那么多各式各样的框架，一些语意晦涩的思想，设计模式之类的东西。所以最后我认为对象只适合表示数据，而不适合处理数据，必须要有新的思想来弥补它的一些不足 |
| 返回顶楼 | |
|
发表时间：2011-02-03
最后修改：2011-02-03
zrweng 写道 这种实现方式使业务接口非常不清晰，如果暴露为WebService，真不知道让外部怎么使用?得不偿失呀!
由于外部接口的声明定义都被隐藏了，的确显的很不清晰！但这正恰恰反映了传统接口编程的硬伤，因为大多数情况下，业务行为的所需参数和结果本身就是不清晰的！正因为接口编程里把参数和返回值都写死了，所以才使写好的代码再反过来适应外部业务变化的时候显的那么吃力。所以我们干脆在一开始就把业务接口给模糊化，不去理会参数和返回值 |
| 返回顶楼 | |
