所在位置:答疑 - 内容   
er、or的假面向对象和假关联关系
 

Horky(324***340)12:52:26
最近遇到些问题,联想到老师上课时讲过的专家原则,但不是很确定。意思是除了一般的单一职责外,一个调用者的类不应该与太多提供服务的类关联,以避免耦合。哪位同学能再说一下?
北京-高原(47***9)13:59:50
这个问题你尝试一下分别询问群里每个人,你就知道答案了
Horky(324***340)14:07:19
问每一个很麻烦,所以我把你视为中介者,请你来问相关的人,我们之间的交互就简单多了
潘加宇(3504847)14:36:43
专家原则说的是类的资源(成本)和责任(销售)的匹配,和"单一责任"不是一个东西

Horky(324***340)14:44:42
那我还是弄混了 如果不是专家原则,应该是有一个原则讲这个问题的
潘加宇(3504847)14:45:37
你把具体的项目问题说一下

Horky(324***340)14:49:51
现有的类间关系如下,耦合太多  
Horky(324***340)14:49:58

Horky(324***340)14:50:13
目的要解耦
潘加宇(3504847)14:52:15
(1)这个聚合组合乱用的,改成普通关联,把关联名字加上
(2)还是需要具体的内容,ABCD具体是什么,不同的概念结果不同。

潘加宇(3504847)14:53:36
就像课上讲的 人知道狗还是狗知道人,没有具体内容具体上下文,哪里有答案

Horky(324***340)15:02:43
简化一下,开始的关系太复杂三者之间相互关联如下图1,我准备改为下图2,去掉Requestor和Responser之间的信赖,只让Requestor和Manager交互 (甚至可能让Manager不依赖于Requestor, 都变成单向的关系)。就是记得课上讲过的某个原则对得上,想复习复习,提高一下 
  
计划修改后  

潘加宇(3504847)15:06:44
(1)这是什么领域的类图?这几个看起来都是人。一般来说,人-人直接关联,而且还多个关联,很少见
(2)这几个er,or是否只是不同的人在参与某个事件时扮演的角色?
潘加宇(3504847)15:07:00
和什么原则都没关系,基本的概念可能要理一理

Horky(324***340)15:43:35
是有点乱 是一个通讯的类图,功能就是Requestor透过Manager和具体的Responser交换数据。Requestor负责组织请求数据,并提交给Manager, Manager创建Responser。之前的实现会将新建的Responser再交给Requestor,由Requetor和Responser直接交互,Manager又同时有对Responser的一些交互。 
Horky(324***340)15:43:45
再理理
潘加宇(3504847)15:47:08
(1)这里面可能没有关联关系
(2)真正的类可能藏在如何"组织请求数据"、如何"创建Responser"的逻辑里面,你可以看看那些***er,***or里代码最多的地方,里面定义的变量可能才是真正要关心的类