Some better illustrated examples can be found in UBCx: SoftConst2x - Software Construction: Object Oriented Design's course lecture on Coupling.

Another way of thinking of this is, if the original owner (source) object and the owned (target) object share the same life cycle -- that is, the owned exists only when the owner does -- we say that the owner aggregates owned object(s). They share a whole-part relationship.

What I did like very much about the video, was when the instructor pointed out that there's a small fallacy: aggregation, in OOD, does not really imply that owned object(s) must be a list.

Thanks to training for Cycling ’74 Max, had a kind of micro-epiphany about encapsulation, a year or so ago. Nesting devices in one another sounds like a convenience but there’s a rather deep effect on workflow when you start arranging things in this way: you don’t have to worry about the internals of a box/patcher/module/device if you really know what you can expect out of it. Though some may take this for granted (after all, other modular systems have had it for quite a while), there’s something profound about getting modules that can include other modules. Especially when some of these are third-party plugins.

For example, a method definition in Java would be:

class MyClassDef {

    public void setProperty(String propertyVal) { .. }

}

For above, setProperty(..) method is the mutator