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里代码最多的地方，里面定义的变量可能才是真正要关心的类
[2020.01加一套题]UMLChina建模竞赛题大全-题目全文+分卷自测（11套110题）
[新增EA024高校毕业生就业系统]全程字幕-24套UML+Enterprise Architect建模示范视频
[幻灯]4月1-4日-剔除“伪创新”和“无领域”的领域驱动设计-网课
[新增：鸵鸟]软件开发团队的脓包：皇帝的新装、口号党、鸵鸟、废话迷
《软件方法》书中自测题-题目全文+分卷自测（1-8章）16套111题
《非程序员》电子杂志下载（39-51期）
《非程序员》电子杂志下载（1-38期）
中文书籍中对《人月神话》的引用（完结，共110本）：软件工程通史1930-2019、实用Common Lisp编程……
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]
UMLChina服务介绍
