如此开发设计方法是否可行

[david_zf]

小弟今天有一个问题，向请教大家，不知大家对这种开发设计方法是如何看待的
近一段时间，公司领导要求设计人员在进行架构设计和模块设计的时候，需要遵循如下原则：
1 模块间的数据流向必须是单向
一个模块不能具有Get数据的接口，只能有接收数据的接口，模块间的Get通过异步发送的方式实现
2 模块间的交互，必须通过一个中心模块来周转
例如模块A调用模块B的一个接口，需要修改成模块A调用Center模块，Center模块调用模块B，然后将结果在返回给模块A
3 Center模块负责整个系统的所有模块间的交互方向的控制
例如一个模块需要订阅另一个模块的数据，则需要告知Center模块，然后Center模块告知产生数据的模块，将数据发送给订阅模块

公司高层说，这样设计的目的是为了适应多人开发和方便测试，Center模块比较复杂让水平较高的人开发，其他模块比较简单由水平低的人来开发

小弟目前很难接受这些，不知是小弟愚笨还是这个方法本身就是不可行的，或者说这种方式不会达到好的开发和测试的效果，多谢

[nonocast]

太死板，毫无创造力
但从公司高层角度考虑，面对一群乌合之众(不是针对你，指大多数)可能这是一种没有办法的办法
但如果需要改善的话，我个人的建议是，Pair + Unit Test

[david_zf]

是啊，这样的设计工作实在是一种煎熬

[liumingchang]

如果你没有做过相似的系统，你估计会很难了解这样设计。（仅从楼主的支言片语看不出太多的问题） 首先，这样的系统比较大，各模块之间可能会存在各种交互，而彼此又必须独立；第二，作为一个产品，用不同的模块组合就可以得到相关的系统（适应不同种用户的要求，支持不同的项目；如果你只是做一个项目当我没说）；最后，北京西直门立交桥很多人认为有问题，但你可以自己云看一下，如果让你设计你怎么来做。（巧妇也得有米，存在就会有一定的道理，只不过是你能不能理解；很多东西别人也是经过考虑的） 毕业时，你的简历可以写这样精通那样精通，工作了几年，你还敢这样写吗？时间会检验的！

[以专业开发人员为伍]

不知道你所说的“模块”是哪一个层面的。 如果过小，那么就会让整个系统显得死板。如果过大，那么就会在模块内部藏污纳垢，甚至造成一个巨大的所谓“中心”模块变成了梦魇。

引用 楼主 david_zf 的回复:

1 模块间的数据流向必须是单向 一个模块不能具有Get数据的接口，只能有接收数据的接口，模块间的Get通过异步发送的方式实现

不懂这是什么意思，而且数据的“单项流向”根本就是胡说八道。一个模块既可以暴露Get也可以暴露Set功能。所谓“单向接口依赖”不是指一个模块不允许Get。比如说模块X依赖（了解）模块A，那么它就可以对A进行Get或者Set；而此时如果A不能对X直接进行Get也不能直接进行Set，而只能通过依赖倒置的机制来通知宿主，这就是单向依赖了。而谈到数据流向，如果只能单向，那怎么可能实现敏捷的系统呢？你可以看到，不论是X调用A还是A通知X，数据都是畅通的。只不过X依赖于A而A不依赖于X而已。把“单向依赖”理解为“数据单向流动”纯粹是害人。

引用 楼主 david_zf 的回复:

2 模块间的交互，必须通过一个中心模块来周转 例如模块A调用模块B的一个接口，需要修改成模块A调用Center模块，Center模块调用模块B，然后将结果在返回给模块A 3 Center模块负责整个系统的所有模块间的交互方向的控制 例如一个模块需要订阅另一个模块的数据，则需要告知Center模块，然后Center模块告知产生数据的模块，将数据发送给订阅模块

只有特定的功能才需要特定的定制机制，例如一个市政公司向同一个省市的其它市政公司开发某些模块功能，假设他们自己内部有1万个功能，它们只开放其中的10个，那么这很值得写一个模块配置、租约控制的所谓Center系统出来。但是这有一个前提，就是内部的千分之999的模块是直接了当地调用了，仅有很少的功能调用才需要限制。而你们的领导是不是搞行政的啊？反正是自家的企业所以怎么害都没有人敢反对啊？

[以专业开发人员为伍]

向同一个省市的其它市政公司开发某些模块功能 --> 向同一个省市的其它市政公司开放某些模块功能 其实软件公司最怕这种“人来疯”的架构师，这种事情上绝不能冲动和纸上谈兵，而要有大量成功的经验为基础。

引用 楼主 david_zf 的回复:

公司高层说，这样设计的目的是为了适应多人开发和方便测试，Center模块比较复杂让水平较高的人开发，其他模块比较简单由水平低的人来开发

这其实是废话。Center让水平较高的人开发，那么不高Center，原来的模块关联方式，每一个模块中也可以自主地区分出“水平高的人写的代码，和水平低的人写的代码”，也就是说原来的每一个模块有核心和扩展岂不是更好？这种Center根本没有消解整个系统的复杂性，只不过是把一个系统弄成两套系统重复建设了而已。

[以专业开发人员为伍]

引用 楼主 david_zf 的回复:

小弟目前很难接受这些，不知是小弟愚笨还是这个方法本身就是不可行的，或者说这种方式不会达到好的开发和测试的效果，多谢

如果不能给出更多更具体的设计来，那么你们公司领导就是在纸上谈兵。因为这个是基于空洞的甚至学生气的一种“画图游戏”来推理出来的，就好像在地上画个圈然后就使劲想“这个圈可以代表多少种事物”一样，空洞地搞这个游戏。

[laoluo554]

这样的设计很不错，只是我没有胆量实施。问题在于增加了开发工作量。长原来看还是很有效的。

[csdnTimePeriod]

center模块的职能让我想起sql server数据库的数据分发代理。 为什么这样设计可以问问架构师，也许可以从中学到一些，简易你问问架构师，技术性的交流是很好的事。如果是初级程序员，那么更没负担了，可以常问问，进步会很快的。

[david_zf]

多谢大家的回复，尤其是sp1234,现在公司似乎不太强制搞这个了，松了口气

[victo7]

你们高层说那么多无非是想要强调两个设计原则： 1.单一职责 2.接口隔离 但是“一个模块不能具有Get数据的接口，只能有接收数据的接口” 这样的规定有点不太理解。猜测应该是在说单一职责这个原则。 整体看下来，这套方式没有什么问题。关键看你们的架构师级别的人，能否在代码级做出方案来。如果只是纸上谈兵那你们就惨了。

[知道就是你]

单一职责：一个方法只做一件事 ； 你说的那个“中心”，类似于中央处理器（CPU），估计是为了防止核心技术外泄吧！

[Fusuli]

这么做是有一定道理的，去看一下代理模式。你想想有10个对象互相调用复杂还是10个对象都只跟中间一个对象调用复杂，好处很多的