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
简化一下，开始的关系太复杂三者之间相互关联如下图１，我准备改为下图２，去掉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里代码最多的地方，里面定义的变量可能才是真正要关心的类