Design Mode notes (10)-decoration mode (Structural)

Document directory

• Gof Definition
• Motivation
• Key points of the decorator Mode

Gof Definition

Dynamically add some additional responsibilities to an object. The decorator mode is more flexible than the subclass generation function.

Let's take a look at a small example. If we need to develop a tank for the game, apart from the tanks of different models, we also hope to add one or more of the following features to tanks in different scenarios: infrared night vision, amphibious and GPS positioning. The common practice is as follows:

/// <Summary> /// abstract tank /// </Summary> public abstract class tank {public abstract void shot (); public abstract void run ();} // model public class T50: Tank {} public class t60: Tank {} public class t70: Tank {} // various functions in different scenarios are abstracted as interfaces, // If a tank of a certain type requires a certain function, it will inherit this function interface // The ia ib ic below is the function a B C interface // <summary> // has feature T50 model /// </Summary> public class t50a: t50, Ia {}/// <summary> // t60 model with a B functions /// </Summary> public class t60ab: t60, IA, IB {}/// <summary> /// t70 model with three functions of a B c /// </Summary> public class t70abc: t70, IA, IB, IC {}

Motivation

The root cause of the problem described above is that we have used inheritance too much to extend the object's functions ",Inheritance introduces the static characteristics of Lai Xing.Makes this extension method less flexible, and as the number of child classes increases (the number of extended functions), the combination of various child classes (the combination of extended functions) it will lead to expansion of more sub-classes (more inheritance ). So how can we enable "extension of object functions" to be dynamically implemented as needed, while avoiding the problem of subclass expansion caused by "increase of extension functions, so that the impact caused by any "Function Change" is minimized? This requires the decorator ). The following describes the structure of the decoration mode:

Component: corresponding to the tank in the above example.

Concretecomponent: T50 t60 t70 of the tank model.

The three classes decorator concretedecoratora concretedecoratorb will be implemented later.

Public abstract class decorator: Tank {private tank _ tank; Public decorator (tank) {_ tank = tank;} public override void shot () {_ tank. shot ();} public override void run () {_ tank. run () ;}} public class concretedecoratora: decorator {public concretedecoratora (tank): Base (tank) {} public override void shot () {// extended infrared function base. shot ();} public override void run () {base. run () ;}} public class concretedecoratorb: decorator {public concretedecoratorb (tank): Base (tank) {} public override void shot () {// extended amphibious function base. shot ();} public override void run () {base. run () ;}} public class concretedecoratorc: decorator {public concretedecoratorc (tank): Base (tank) {} public override void shot () {// extended location function base. shot ();} public override void run () {base. run ();}}

Client call

Public class app {static void main () {tank = new T50 (); // has the infrared function concretedecoratora da = new concretedecoratora (tank ); // features concretedecoratorb DB = new concretedecoratorb (DA); // features including infrared, amphibious, and positioning: concretedecoratorc Dc = new concretedecoratorc (db ); // functions can be combined at Will here. To expand a function, you only need to // Add a specific function class to inherit the decorator }}

Key points of the decorator Mode

By combining rather than inheriting, the decorator mode enables dynamic extension of object functions at runtime, and supports multiple functions as needed. This avoids the "poor flexibility" and "Multi-subclass Derivative Problems" caused by the independent use of inheritance ".

The component class acts as an abstract interface in the decorator mode and should not implement specific actions. In addition, the decorator class should be transparent to the component class. In other words, the component class does not need to know the decorator class. The decorator class expands the functionality of the component class from the outside.

The decorator class represents the inheritance relationship of is-a component on the interface, that is, the decorator class inherits the interface of the component class. However, the implementation is manifested in the composite relationship of has-a component, that is, the decorator class uses another component class. We can use one or more decorator objects to "Decorate" a component object, and the decorated object is still a component object.

The decorator mode does not solve the problem of "Multi-subclass-derived multi-inheritance, the main point of the decorator mode application is to solve the problem of "the extension function of the Subject Class in multiple directions", which is the meaning of "decoration.

Return to the beginning (INDEX)