. Net: A Brief Introduction to the design model (what about the performance of the decorator model ?)

Let me assume that I want to read this articleArticleAll of your friends have a deep understanding of the decorator model. This article discusses the performance of the modifier mode.

In my ". net briefly introduces the design pattern (the decorator pattern), which describes in detail the general applications of the decorator pattern. However, I always feel that the decorator pattern is a bit imperfect. After a whole day of thinking and thinking yesterday, I finally found out what the imperfections in the vague conventions are, and inherited the innocent performance overhead for behavior. So I want to write it out and discuss with you how to balance the performance of the modifier mode. Whether to use time for space or space for time, the time here is the efficiency time of our development.

First, let's review the intention of the Paster model. It officially means to dynamically add some additional responsibilities to an object. We all know that the object extension function is implemented through inheritance, but inheritance has its disadvantages, such as the coupling between subclass and parent class, and the infinite expansion of subclass. The modifier mode is to dynamically add functions to objects to be extended. Independent of the kinetic energy that needs to be expanded, as a decoration class, put on this decoration for the object as needed.

1:

As shown in this figure, this class chart has grown so far that sub-classes are infinitely inflated that no one knows what to expect. This is a normal method for extending objects. Let's take a look at the prototype of the modifier mode.

2:

Separate the functions to be extended and dynamically add functions as needed. I think this is why the name of the decorator comes from. It is a good image to compare the extended functions of the decorator.

But when we look at the principle of this imageCodeIts structure is not "clean" at all ".Therefore, theories and practices are inseparable.. See the Code:

Using system; using system. collections. generic; using system. text; namespace consoleapplication2 {public class concreteconpontent {Public Virtual void operation () {console. writeline ("top-level objects to be decorated");} Public Virtual void message () {console. writeline ("top-level object message") ;}} public abstract class decorator: concreteconpontent {protected extends m_compontent; Public void setcompontent (paicom) {m_compontent = com ;}} public class concretedecoratora: decorator {public override void operation () {m_compontent.operation (); console. writeline ("concretedecoratora dynamically adds methods");} public override void message () {m_compontent.message (); console. writeline ("concretedecoratora added the message method dynamically") ;}} public class concretedecoratorb: decorator {public override void operation () {m_compontent.operation (); console. writeline ("concretedecoratorb decorated the method");} public override void message () {m_compontent.message (); console. writeline ("concretedecoratorb added the message method dynamically");} public class concretedecoratorc: decorator {public override void operation () {m_compontent.operation (); console. writeline ("concretedecoratorc decorated the method");} public override void message () {m_compontent.message (); console. writeline ("concretedecoratorc added the message method dynamically ");}}}

 

The basic code prototype of the modifier mode is similar to this. When I see that the decorator mode is such a code structure, I feel uncomfortable. Does it carry inheritance? Why do we need to inherit from it? I cannot bear to complain. Concreteconpontent is the object of the decorator. First, make sure that the object to be extended can be extended. In fact, I know that inheritance is used to get the behavior of objects to be extended, and it indicates that all the decorators belong to one type, you can use the base class to use all the decorators. If there is no inheritance, it is clear that the base class cannot be called in a unified manner. Inheritance also plays a role in obtaining the actions of the decorator and using it to operate different instances, it is smart enough.

3:

If I don't need to use a base class to call the decorator in a unified way, can I inherit from the decorator? In order to realize the infinitely increasing Decoration of the decorator, I made a simple modification to the code. Please refer to the Code:

Using system; namespace consoleapplication1 {public class concreteconpontent {Public Virtual void operation () {console. writeline ("top-level objects to be decorated");} Public Virtual void message () {console. writeline ("top-level object message") ;}} public abstract class decorator {private concreteconpontent m_compontent; protected decorator; Public void setcompontent (concreteconpontent COM, decorator de) {m_compontent = com; Decorator = de;} public void setcompontent (concreteconpontent com) {m_compontent = com;} Public Virtual void operation () {If (decorator! = NULL) decorator. Operation (); else m_compontent.operation ();} Public Virtual void message () {If (decorator! = NULL) decorator. message (); else m_compontent.message () ;}} public class concretedecoratora: decorator {public override void operation () {base. operation (); console. writeline ("concretedecoratora decorated with methods");} public override void message () {base. message (); console. writeline ("concretedecoratora added the message method dynamically") ;}} public class concretedecoratorb: decorator {public override void operation () {base. operation (); console. writeline ("concretedecoratorb decorated the method");} public override void message () {base. message (); console. writeline ("concretedecoratorb added the message method dynamically") ;}} public class concretedecoratorc: decorator {public override void operation () {base. operation (); console. writeline ("concretedecoratorc decorated the method");} public override void message () {base. message (); console. writeline ("concretedecoratorc added the message method dynamically ");}}}

If we want to extend a simple small function, it is not worthwhile to inherit a large object. Just want to use the actions of the decorator to operate the decorator prototype instance. We can sacrifice code redundancy to solve this performance problem.The inheritance in the book is used to avoid manual input of the behavior code of the decorator.. I don't think this is convincing. Without inheritance, I can have the same behavior, and can implement an infinitely increasing nested modifier instance. If you want to set instances for an instance, they must come from the same ancestor, also the decorator. If you want the decorator to set the decorator, in this case, a reference to the modifier type is required for the modifier class, but each modifier cannot be the same. Therefore, they must inherit the same base class. As long as there are more decorators that inherit the same base class, they can reference each other.[Wang qingpei has all rights reserved. For more information, please sign it.]

Conclusion: When we select the decorator mode, we need to modify it based on our usage. You do not need to inherit an object that is so large without any need.