外观设计模式的关联或聚合关系?

本文介绍了外观设计模式的关联或聚合关系?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我正在研究GoF设计模式，尤其是Facade模式.我了解它的使用和实现，但对它的UML模型有疑问.我的教授提出的解决方案总结如下:

I'm studying the GoF design patterns, in particular the Facade pattern. I understand its use and implementation, but I have a doubt about its UML model.The solution proposed by my professor, summarized, is the following:

public class Facade{
    private ClassA c1;
    private ClassB c2;
    private ClassC c3;

    public Facade(){
        this.c1 = new ClassA;
        this.c2 = new ClassB;
        this.c3 = new ClassC;
    }

    public void FacadeMethod(){
        ...
        c1.operationA();
        c2.operationB();
        c3.operationC();
        ...
    }

}

提出的UML模型是这样的:

The UML model proposed is like this:

外观类与类A，类B，类C具有关联关系.但是，这些应该是聚合关系吗?外观类将c1引用为ClassA，将c2引用为ClassB，将c3引用为ClassC，因此我认为它是"HAS-A"引用.关系.有想法吗?

The Facade Class has an association relationship with the classes ClassA, ClassB, ClassC. However should these be aggregation relationships? The Facade Class has reference c1 to ClassA, c2 to ClassB and c3 to ClassC, so i think it's a "HAS-A" relationship. Any Idea?

初步说明

许多消息来源倾向于使用 UML聚合以图形方式表示对象组成.鼓励这种趋势的流行资源例如是维基百科.但是，不建议这样做.

Preliminary remark

Many sources tend to use UML-aggregation for graphically representing object-composition. A popular source encouraging this trend is for example wikipedia. This is however not to be recommended.

您的教授在立面实现的代码中使用对象组成，并使用可导航的关联是正确的.一些专家声称，使用关联端的点表示法会更好所有权

Your professor uses object-composition in the code of the facade implementation, and represents this with a navigable association which is correct. Some experts claim that this would be much better to use the dot notation of the association end ownership

您的教授使用对象组合和前向外观调用对象.这是立面的有效实现:

Your professor uses object-composition and forward facade calls to objects. This is a valid implementation of a facade:

GoF 明确声明第187页"[[facade]委托客户端"请求到适当的子系统目标"显然可以进行对象组合.

GoF explicitly states page 187 that "[the facade] delegate client requests to appropriate subsystem objets" which clearly allow object-composition.

尽管这不是实现外观的最常用方法(通常使用类方法)，但GoF进一步描述了第188页的实现替代方法:

While this is not the most commonly used way to implement a facade (often class-methods are used instead), GoF further describes implementation alternatives page 188:

从表面上看，使用UML聚合对对象组成进行建模似乎根本不是错误的:UML不能很好地定义聚合语义，并为解释留有余地.在 UML规范的第110页中，其解释如下:

In apparence, using UML-aggregation for modelling object-composition does not seem fundamentally wrong: UML does not define aggregation semantic very well and leaves room for interpretation. On page 110 of UML specs it's explained that:

" 共享聚合(又名白钻)的精确语义因应用领域和建模者而异 "-那么为什么不(误)将其用于对象合成

an aggregation is when one instance is used to "group together a set of instances" - but nothing forbids the set to be limited to one member.
"Precise semantics of shared aggregation (aka white diamond) varies by application area and modeler" - so why not (mis)use it for object composition

虽然这是一个有效的解释，但它具有一些缺陷:

While this is a valid interpretation, it comes with some flaws:

考虑到一组实例"的措辞，许多建模者可能会误解该聚合在默认情况下具有 * 多重性，并且默认情况下集合不是单例的.当使用UML聚合进行对象组合时，应明确指出1的多重性，以免造成误解.

Many modellers migh misunderstand the aggregation to have a * multiplicity by default, in view of the wording "a set of instances", and sets are not by default singletons. When UML-aggregation is used for object composition the multiplicity of 1 should be made explicit to avoid misunderstandings.

更仔细地阅读第110页显示，聚合实际上意味着对整体关系进行建模.因此，在其他情况下将其用于对象组合是对UML聚合的误用(不是错误，但不是故意的):

A more carefull reading of page 110 shows that aggregation is in reality meant to model a part-whole relationship. Using it for object-composition in other cases is therefore a misuse of the UML aggregation (not wrong, but not the intent):

对对象组的这种解释在第198页上得到了加强，可以理解，UML复合聚合和共享聚合之间的主要区别在于聚合项目的所有权:

This interpretation of groups of objects is reinforced page 198, being understood that the main difference between UML composite aggregation and shared aggregation is the ownership of the aggregated items:

Uli的创建者

Booch，Rumbaugh和Jacobson在他们的非规范但更易读的书" UML用户指南"中证实了这一点:

考虑到这种弱语义，我们可以总结: UML聚合可以使用对象组合来实现.但并非所有的对象组合都实现UML聚合.这不是两个概念之间的一对一映射.

Taking into account this weak semantic, we can summarize: UML-aggregation may be implemented using object-composition. But not all object-composition implement UML-aggregates. It's not a one-to-one mapping between both concepts.

我们可以从马丁·福勒(Martin Fowler)的名著"UML Distilled"(UML蒸馏)一书中得出结论.在其中，他分析了难以解释聚合与正常关联之间的差异的难度，而与实现方面的考虑无关:

We can conclude with Martin Fowler's quote out of his excellent book "UML Distilled" in which he analyses the difficulty to explain the difference between aggregation and a normal association, independently of any implementation considerations:

这篇关于外观设计模式的关联或聚合关系?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

ClassC