Conflict between inheritance and aggregation in decorator mode

One: Background: Decorator

*decorator is often translated into "decoration", I think the translation into a "painter" more image point, painter (decorator) is used to brush paint, then the object of painting paint we call decoratee. Both entities are required in the decorator model.

*decorator definition:

Dynamically add some extra responsibility to an object, like paint on a wall. Using decorator mode to achieve functional expansion is more flexible than generating subclasses.

* Why use Decorator?

We can usually use inheritance to extend the functionality, if these need to expand the variety of functions, it is bound to generate a lot of subclasses, increase the complexity of the system, at the same time, the use of inheritance to achieve functional expansion, we must be able to foresee these expansion functions, these functions are compiled when it is determined, is static.

The rationale for using decorator is that these features require the user to dynamically decide how and when to join. Decorator provides a "Plug and Play" method that determines when to add functionality during run time.

* For the model, it is initially summed up as

1. Basic ability for Interface

The 2.Decorator parameter is the interface itself and the interface for the next decorator parameter

3. The basic function class implements the interface and acts as a parameter to the decorator constructor to add new functionality on this basis

4. Additional functionality is handled by the data structure in decorator

Two: Questions

This is an example of a decorator design pattern implemented as follows:

Basic function: Counter class

Features that need to be added

1: Upper Control