Structural mode: decorator mode, composite mode, and proxy Mode

Source: Internet
Author: User

 

Decorator mode:

In the process of object-oriented design and development, you may often encounter the following situations. We need to add new responsibilities for a defined class, in this case, we will define a new class to inherit the custom class, and solve this situation through inheritance will bring about system complexity, because the depth of inheritance will become very deep. The decorator provides a method to add responsibilities to the class, not through inheritance, but through combination.

The decorator decoration mode is a structural mode, which mainly solves the following problems: "excessive use of inheritance to extend object functions", because inheritance is a type-introduced static characteristic, the lack of flexibility in this expansion method. 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 ). Inheritance refers to the static characteristics introduced by the type, which means that the function to be obtained for a certain type in the inheritance mode is compiled. Static refers to compiling; Dynamic refers to running.

Example:

# Pragma once

 

# Ifndef _ decorator_h

# DEFINE _ decorator_h

 

Class component

{

Public:

Virtual ~ Component ();

Virtual void operation ();

Protected:

Component ();

PRIVATE:

 

 

};

 

Class concretecomponet: public component

{

Public:

Concretecomponet ();

~ Concretecomponet ();

Void operation ();

Protected:

PRIVATE:

 

};

 

Class decoratorclass: public component

{

Public:

Decoratorclass (component * COM );

Virtual ~ Decoratorclass (void );

Void operation ();

Protected:

Component * _ com;

PRIVATE:

 

};

 

Class concretedecorator: Public decoratorclass

{

Public:

Concretedecorator (component * COM );

~ Concretedecorator ();

Void operation ();

Void addedbehavior ();

Protected:

PRIVATE:

 

};

# Endif

 

//////////////////////////////////////// //////////////////////////////////////// //

# Include "stdafx. H"

# Include "decoratorclass. H"

 

# Include <iostream>

Using namespace STD;

 

Component: component ()

{

Cout <"component construct..." <Endl;

}

 

Component ::~ Component ()

{

Cout <"component exit..." <Endl;

}

 

Void component: Operation ()

{

Cout <"component operation..." <Endl;

}

 

Concretecomponet: concretecomponet ()

{

Cout <"concrete component construct..." <Endl;

}

 

Concretecomponet ::~ Concretecomponet ()

{

Cout <"concrete component exit..." <Endl;

}

 

Void concretecomponet: Operation ()

{

Cout <"concretecomponet operation..." <Endl;

}

 

Decoratorclass: decoratorclass (component * COM)

{

This-> _ COM = com;

}

 

Decoratorclass ::~ Decoratorclass (void)

{

Delete _ com;

}

 

Void decoratorclass: Operation ()

{

 

}

 

Concretedecorator: concretedecorator (component * COM): decoratorclass (COM)

{

 

}

 

Concretedecorator ::~ Concretedecorator ()

{

 

}

 

Void concretedecorator: addedbehavior ()

{

Cout <"concretedecorator: addedbehacior..." <Endl;

}

 

Void concretedecorator: Operation ()

{

_ Com-> operation ();

This-> addedbehavior ();

}

 

//////////////////////////////////////// //////////////////////////////////////// //////////////////////////////////////// /////////////

// Decorator. cpp: defines the entry point of the console application.

//

 

# Include "stdafx. H"

# Include "decoratorclass. H"

# Include <iostream>

Using namespace STD;

 

 

Int _ tmain (INT argc, _ tchar * argv [])

{

Component * COM = new concretecomponet ();

Decoratorclass * dec = new concretedecorator (COM );

Dec-> operation ();

Delete Dec;

 

Return 0;

}

 

 

 

Composite mode:

 

The composite combination mode mainly deals with the following problems: a class of objects with "Container characteristics"-that is, they act as objects while serving as containers of other objects. During writing, we often cause that the customer code is too dependent on the complex internal implementation of the object container, and the internal implementation structure of the object container (rather than the abstract interface) the changes will cause frequent changes in the customer's code, and lead to the defect of code maintainability and scalability.

Gof "design patterns" says: Combine objects into a tree structure to represent a "part-whole" hierarchy. The composite mode ensures consistency between the use of a single object and a composite object.

 

Proxy mode:

 

The proxy mode is a structural design mode. It mainly solves the problems caused by direct access to objects. For example, the objects to be accessed are on a remote machine. For example, C and A are not on the same server. A needs to call C frequently. We can create a proxy class proxy on a and hand over the work of accessing C to proxy. For, it is like directly accessing the C object. In the development of A, we can focus entirely on the implementation of the business.

 

Example:

# Pragma once

 

# Ifndef _ proxy_h

# DEFINE _ proxy_h

 

Class subject

{

Public:

Virtual ~ Subject ();

Virtual void request () = 0;

Protected:

Subject ();

PRIVATE:

 

};

 

Class concretesubject: public subject

{

Public:

Concretesubject ();

~ Concretesubject ();

Void request ();

Protected:

PRIVATE:

 

};

 

 

 

Class proxyclass

{

Public:

Proxyclass (void );

Proxyclass (subject * sub );

~ Proxyclass (void );

Void request ();

Protected:

PRIVATE:

Subject * _ Sub;

};

# Endif

 

//////////////////////////////////////// //////////////////////////////////////// //////////

# Include "stdafx. H"

# Include "proxyclass. H"

 

# Include <iostream>

Using namespace STD;

 

Subject: subject ()

{

 

}

 

Subject ::~ Subject ()

{

 

}

 

Concretesubject: concretesubject ()

{

 

}

 

Concretesubject ::~ Concretesubject ()

{

 

}

 

Void concretesubject: Request ()

{

Cout <"concrete subject... request" <Endl;

 

}

 

Proxyclass: proxyclass (void)

{

 

}

 

Proxyclass: proxyclass (subject * sub)

{

_ Sub = sub;

}

 

Proxyclass ::~ Proxyclass (void)

{

Delete _ Sub;

}

 

Void proxyclass: Request ()

{

Cout <"proxy request..." <Endl;

_ Sub-> request ();

}

 

//////////////////////////////////////// //////////////////////////////////////// ////////////

 

# Include "stdafx. H"

# Include "proxyclass. H"

# Include <iostream>

Using namespace STD;

 

Int _ tmain (INT argc, _ tchar * argv [])

{

Subject * sub = new concretesubject ();

Proxyclass * P = new proxyclass (sub );

P-> request ();

 

Return 0;

}

 

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.