【问题标题】:If the aggregation is enough or should I connect aggregated classes too如果聚合足够,或者我也应该连接聚合类
【发布时间】:2019-06-01 09:27:56
【问题描述】:

我有一个问题。如果 ClassA 聚合 ClassB 和 ClassC 并且 ClassA 调用 Class C 的方法,其中它使用 ClassB 对象的属性(通过参数传递)我应该连接 ClassB 和 ClassC 还是聚合就足够了?

图片例如: Diagram UML

实施:

class ClassA {
    constructor() {
        this.stringA = "Hello"
        this.objB = new ClassB();
        this.objC = new ClassC();
    }
    functionA() {
        this.objB.functionB(this.stringA);
        this.objC.functionC(this.objB.intB);
    }
}

class ClassC {
    constructor() {}
    functionC(intB) {
        console.log(intB);
    }
}

class ClassB {
    constructor() {
        this.intB = 10;
    }
    functionB(stringA) {
        console.log(stringA);
    }
}

感谢您的帮助

【问题讨论】:

标签: variables uml aggregation


【解决方案1】:

在您的图表中,您使用组合,而不是“只是”聚合,这意味着当 ClassA 的实例消失时,ClassB 和 ClassC 的实例也会消失。 p>

组合聚合的目标并不是说一个类调用另一个类的方法或使用它的一个属性。

如果 ClassB 使用 ClassC 的属性(已经很奇怪了,它是公共的吗?)你可以使用依赖,但是如果你每次都冒着在很多类之间存在依赖的风险添加一个依赖,并且目标类图并不是真正表明这一点

【讨论】:

  • 因此,如果我在 ClassB 和 functionA 中为 intB 创建一个 getter,我将调用该 getter (this.objC.functionC(this.objB.getIntB()) 我不需要使用依赖项ClassB 和 ClassC 之间?
  • functionC 在参数中接收到 _this.objB.getIntB() 的值,但是 ClassB 不知道,也可能是 ClassC,这不是细节吗?如果一个类使用另一个类的事实真的很重要,您可以通过依赖项表明这一点,但定义接口和组件以显示 require/provide 可能更好?一张图不能像蜘蛛网一样复杂化所有之间的关系
猜你喜欢
  • 2012-12-23
  • 1970-01-01
  • 1970-01-01
  • 2015-10-31
  • 1970-01-01
  • 2019-01-12
  • 2013-01-08
  • 2021-10-08
  • 2020-01-12
相关资源
最近更新 更多