Your book explains quite good so let me elaborate and provide you some examples.

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

Sometime a class may logically need to be big. But big class is not a good coding pratice. Also sometime, some functionalities of a class may be implementable in more than one way and you may want to change that some time.

class FeatureHolder { void feature() { // Big implementation of the feature that you dont want to put in the class Big } } class Big { private FeatureHolder FH = new FeatureHolder(); void feature() { // Delegate to FeatureHolder. FH.feature(); } //.. Other features }

From the above example, Big.feature() call feature of FH as is without changing it. This way, the class Big does not need to contain the implementation of the feature (separation of labour). Also, feature() can implement differently by other class like "NewFeatureHolder" and Big may choose to use the new feature holder instead.

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

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

Technially, Composition is "part of" and Aggregation is "refer to" relationship. Your arms are part of you. If you no longer live, your arm will die too. Your cloth is not part of you but you have them; as you can guest, your cloth does not go with you.

In programming, some objects are part of another object and they have no logical meaning without it. For example, a button is composed into a window frame. If a frame is closed, the button has no reason to be around anymore (Composition). A button may have reference to a database (like to refreash data); when the button is eliminated, the database may still be around (Aggregation).

Sorry for my English, Hope this helps