Design Pattern---Adorner mode (c + + implementation) __c++

Adorner mode (decorator pattern) allows new functionality to be added to an existing object without altering its structure. This type of design pattern is a structural pattern and is a wrapper for an existing class.

This pattern creates a decorative class that wraps the original class and provides additional functionality while preserving the integrity of the class method signature.

Intent

Dynamically adds additional responsibilities to an object. Adorner mode is more flexible than generating subclasses in terms of adding functionality.

solve the problem

In general, we often use inheritance to extend a class, because inheritance introduces static characteristics to a class, and as the expansion function increases, subclasses swell.

How to solve

Dividing specific functional responsibilities and inheriting adorner mode

Advantages

Decorative classes and decorated classes can be developed independently, will not be coupled, decorative mode is an inherited alternative mode, decorative mode can dynamically extend the function of a implementation class.

Disadvantage

Multilayer decoration is more complicated

Attention Matters

Can replace inheritance

C + + implementation

There is a mobile phone that allows you to add features to your phone, such as adding pendants, screen stickers, and so on. A flexible design is to embed the phone in another object, by which the object completes the addition of the attribute, which we call the embedded object to be decorated. This decoration is consistent with the interface of the component it decorates, so it is transparent to the customer that uses the component.

The adorner pattern UML diagram is given below:

In this design, the mobile phone's decorative function is independent, can develop independently, and thus simplifies the specific mobile phone class design.

Code:

Adorner mode class Phone {Public:phone () {} virtual ~phone () {} virtual void Showdecorate () {}}; 
	Class Iphone:public phone//specific mobile private:string name Public:iphone (string _name): Name (_name) {} ~iphone ()
	{} void Showdecorate () {cout << name<< "decoration" << Endl;
}
}; Class Nokiaphone:public Phone {private:string name; Public:nokiaphone (string _name): Name (_name) {} ~nokiapho
	NE () {} void Showdecorate () {cout << name << "decoration" << Endl;

}
}; Class Decoratorphone:p ublic phone {private:phone* m_phone;//To decorate the mobile Public:decoratorphone (telephone *phone): M_phone (
	Phone) {} virtual void Showdecorate () {m_phone->showdecorate ();

}
}; Class Decoratephonea:public Decoratorphone//specific decoration a {public:decoratephonea (phone* ph):D ecoratorphone (ph) {} Voi
		D showdecorate () {decoratorphone::showdecorate ();
	Adddecorate ();
	} private:void Adddecorate () {cout << "add pendant" << endl;
}
}; Class DEcoratephoneb:public Decoratorphone {public:decoratephoneb (phone* ph):D ecoratorphone (ph) {} void Showdecorate ()
		{decoratorphone::showdecorate ();
	Adddecorate ();
	} private:void Adddecorate () {cout << "screen foil" << Endl; }
};

Client:

int test_decorate ()  //Adorner mode
{
	phone* ph = new Nokiaphone ("16300");
	Phone *DPA = new Decoratephonea (ph),//Add pendant
	phone* DPB = new Decoratephoneb (ph);//Add Foil
	ph->showdecorate ();

	Delete ph;
	Delete dpa;
	Delete DPB;
	System ("pause");
	return 0;
}

The decorative pattern provides a more flexible way to add responsibilities to an object. You can add and remove responsibilities with decorations at run time using the addition and separation methods. The decorative pattern provides a "pay-by-one" approach to add responsibilities. Rather than trying to support all the predictable features in a complex customizable class, instead, you can define a simple class and gradually add functionality to it with a decorative class. Complex functions can be assembled from simple parts. [DP]
In the example of this article, we have defined two specific mobile phone classes, iphone classes and Nokiaphone classes that add features to them through separate decorative classes to combine complex functions.

The difference from bridging mode:

Before summarizing the C + + design mode-bridging mode; you will find that both are designed to prevent excessive inheritance, resulting in the spread of subclasses. So what is the main difference between the two? Bridging mode is defined as separating abstraction from implementation (in a combination rather than an inherited way), allowing the two to change independently. You can reduce the growth of your derived classes. If the light from this point of view, and the decoration is similar, but there are some important differences between the two:

1. The separation in the bridging mode, in fact, it means separating the structure from the implementation (when the structure and implementation are likely to change) or attributes being separated from the property based behavior, while the decorator simply closes the property based behavior into a separate class to decorate it, that is, to extend it. For example: The exception class and the exception handling class can use the bridge pattern to accomplish, but cannot use the adornment pattern to carry on the design; if we need to extend the handling of the exception, we can add decorator to the exception handling class to add the processing decoration to the extension of exception handling. This is a bridge mode and decorative mode of collocation;

2. The behavior in bridging is horizontal behavior, the behavior is not related to each other, note that there is no correlation between the behavior here, for example, there is no behavioral association between exception and exception handling, and the behavior in the decorator pattern is additive, and the result is a whole, a result of the combination of each behavior.

Summary

Decorative patterns focus on decoration, the role of the core functions of decoration; Converts the extension of the child classes in inheritance into a combination of functional classes, thus passing on the extension of the subclass to the user to make the invocation combination, and how the user is grouped by the user to decide. When I study the decoration mode, I focus on analyzing the word "decoration", we all know that decoration is a core function to add some ancillary functions, so that the core function to play a greater role, but ultimately its core functions can not be lost. This is like when we were doing Windows shell development, we were decorating the shell of windows to achieve some of the decorative features we needed, but the final feature was done by the Windows shell. This is like, our decoration is to add a layer of the core function, make it look more beautiful and perfect.

Reference:
Http://www.jb51.net/article/55882.htm

http://blog.csdn.net/wuzhekai1985/article/details/6672614