耦合度太高还是可以这样设计？答案

【问题标题】：Too high coupling or okay to design like this?耦合度太高还是可以这样设计？
【发布时间】：2015-10-13 13:14:29
【问题描述】：

假设我有一个classA，它有自己的方法和自己的私有字段以及你有什么（基本上遵守封装标准）。然后我有classB，它的执行需要classA 的最终状态（通过classA 的一种方法获得，这在某种程度上破坏了封装）。然后我们有classC，这又需要classB 的最终状态。等等等等，让我们说classM。这是否认为耦合太高？

编辑：好吧，假设我在设计战利品系统，这取决于掉落是否基于敌人被击败（每个敌人有不同的掉落机会）。如果敌人被击败，处理战斗物品的班级会掷骰子，无论它是否掉落东西，然后我需要将该状态传播给处理战利品分配的其他班级。如果有掉落，处理战利品的类执行战利品生成并分发给玩家，如果没有，则无效。

最终的执行是这样的：

classA a = new classA;
...  //classA does its stuff
classB b = new classB(a.getFinalState());
... // again class does its stuff based on outcome of A
classC c = new classC(b.getFinalState());

等等。

【问题讨论】：

我不明白这里的问题？为什么不直接将对象 a 传递给对象 b 的构造函数呢？它可以在不破坏封装的情况下通过正常的方式对其进行询问以确定状态。如果您担心暴露太多，也许可以尝试使用包私有 getter 或将接口隔离到自己的模块？你问的问题很好，但想得太难了。 ;-)

标签： java class coupling

【解决方案1】：

是的。与级别 2 紧密耦合。这是可以高度避免的，并且被认为是降低代码灵活性和可重用性的不良做法。测试是一场噩梦。

如果它们具有相互关联的属性，请考虑查看Builder Pattern。

构建器模式是为了解决伸缩构造器反模式

构造函数反模式就是你目前所拥有的。

【讨论】：

【解决方案2】：

编辑：您可以通过关注Delegation Pattern 及其近亲Decorator Pattern 来实现您想要的目标

如前所述，Builder Pattern 是一个有效的替代方案。这始终取决于您的原始设计目标。

【讨论】：

我的错，我实际上编辑了我的原始帖子以将我当前的问题包含在问题中