区分委派，组合和聚合(Java OO设计) [英] Distinguishing between delegation, composition and aggregation (Java OO Design)

问题描述

我面临着一个持续的问题，那就是将委派，组成和聚合彼此区分开，并确定在哪种情况下最好使用一种.

我查阅了一本Java OO分析和设计书，但是我的困惑仍然存在.主要的解释是这样的:

委派:当我的对象按原样使用另一个对象的功能而不更改它时.

组成:我的对象由其他对象组成，这些对象在销毁了我的对象后就不复存在了.

聚集:我的对象由其他对象组成，这些对象即使在我的对象被销毁后也可以存在.

是否有几个简单的示例可以说明每种情况及其背后的原因?除了我的对象仅引用另一个对象之外，这些示例还可以如何展示?

解决方案

在所有三种情况下，您的对象都将引用另一个对象.区别在于所引用对象的行为和/或生命周期.一些例子:

1. 组成:房屋包含一个或多个房间.房间的寿命由房子控制，因为没有房子就不会存在房间.

2. 集合:由积木建造的玩具屋.您可以拆卸它，但块会保留.

3. 委托:您的老板要您给他喝杯咖啡，您已经为它做过实习生.委托不是一种关联类型(就像组合/聚合一样).后两者已经在Stack Overflow 很多次

上进行了讨论.

在评论中，您询问在每种情况下实现会有所不同，请注意在所有情况下我们都会在已发布对象上调用方法.的确，在每种情况下，我们都会有类似

的代码

myRoom.doWork();

myBlock.doWork();

myMinion.doWork();

但是区别在于相关对象的生命周期和基数.

对于组件，创建房屋时，房间即已存在.因此，我们可以在众议院的构造函数中创建它们.

在协会(我将使用Tire和Car)的情况下，汽车可能会在其构造函数中添加Tires，但是稍后您可能想要移除和更换轮胎.因此，您也可以使用诸如

 removeTyre(FrontLeft)
 addNewTyre(aTyre, BackRight)

很有可能aTyre对象来自Factory-我们在Car的任何方法中都没有new它.

对于委派，您甚至可能没有成员变量来保存委派

 resourcingPool().getIntern().getCoffee(SkinnyLatte, workstation 7);

对象之间的关系仅在实习生取咖啡时才持续.然后返回到资源池.

I am facing a continuing problem distinguishing delegation, composition and aggregation from each other, and identifying the cases where it's the best to use one over the other.

I have consulted a Java OO Analysis and Design book, but my confusion still remains. The main explanation is this:

Delegation: When my object uses another object's functionality as is without changing it.

Composition: My object consists of other objects which in turn cannot exist after my object is destroyed-garbage collected.

Aggregation: My object consists of other objects which can live even after my object is destroyed.

Is it possible to have a few simple examples demonstrating each case, and the reasoning behind them? How else can these examples be demonstrated other than my object simply having a reference to another object(s)?

解决方案

Your object would reference another object(s) in all three cases. The difference lies in behavior and / or lifecycle of referenced objects. Some examples:

1. Composition: House contains one or more rooms. Room's lifetime is controlled by House as Room will not exist without House.

2. Aggregation: Toy house built from blocks. You can disassemble it but blocks will remain.

3. Delegation: Your boss asked you to get him a coffee, you've had an intern do it for you instead. Delegation is not a type of association (like composition / aggregation are). The latter two have been discussed on Stack Overflow many times

In the comment you ask how the implementation would differ in each case, observing that in all cases we invoke methods on the releated objects. It's true that in each case we would have code such as

myRoom.doWork();

myBlock.doWork();

myMinion.doWork();

but the differences lie in the life-cycle and cardinality of the related objects.

For the Component, the Rooms come into existence when the House is created. So we might create them in the constructor of the House.

In the case of Association (I'll use Tyre and Car) Cars might add Tyres in their constructor, but later you may want to remove and change tyres. So you also have methods such as

 removeTyre(FrontLeft)
 addNewTyre(aTyre, BackRight)

And it's quite likely that the aTyre object came from a Factory - we didn't new it in any of the Car's methods.

In the case of Delegation, you might not even have a member variable to hold the delegate

 resourcingPool().getIntern().getCoffee(SkinnyLatte, workstation 7);

the relationship between the objects lasts only as long as the intern is fetching the coffee. Then it returns to the resource pool.

这篇关于区分委派，组合和聚合(Java OO设计)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！