An example of the Android Design Pattern gives you a thorough understanding of the Decorator Pattern)

An example of the Android Design Pattern gives you a thorough understanding of the Decorator Pattern)
Guide

In this article, I will not use conceptual text to describe the decorator mode, because the conceptual issues are usually abstract and difficult to understand, making it difficult for readers to understand why this design mode is used, the birth of our design pattern must have been a certain difficulty encountered by our predecessors when designing the program. In order to avoid this kind of suffering, we designed this design pattern, so in this article, I will lead you to this difficulty and use the design mode to solve this problem. Finally, you will understand what the designer mode is, when should I use the designer mode and how should I use the designer mode?

First, let's take a look at what the UML diagram of the decorator mode looks like. It doesn't matter if the meaning of each class in the diagram doesn't understand. Below I will introduce them one by one using an image example, I believe you will understand it after reading it.

What will happen if you don't need the decoration designer's design pattern?

Here, I am not allowed to use some conceptual text to explain what the decorator mode is. I will use an actual example to illustrate what the decorator mode is!
For example, to play online games, we must first create a role, right? Each of these roles is created differently, because the role can certainly be customized based on the user's aesthetic, however, each role's initial capabilities are the same, and it won't become very powerful because a player has made him a very handsome face. This role must be an interface. This is the Conponent interface in the UML diagram.

/*** Game role */public interface Avatar {void describe ();}

It is very simple. There is only one method. We only use it for demonstration. It is impossible for a real game role to be so simple. The describe method is used to describe this role.

Well, we certainly have a career in playing games, right? Suppose we have only designed four categories of games: Worrior, Mage, Hunter ), warlock ). We need to create four implementation classes, which correspond to the ConcreteComponent class.

Public class Worrior implements Avatar {@ Override public String describe () {return "warrior ";}}

Public class Mage implements Avatar {@ Override public String describe () {return "Mage ";}}

Public class Hunter implements Avatar {@ Override public String describe () {return "Hunter ";}}

Public class WarLock implements Avatar {@ Override public String describe () {return "";}}

Now we have created four professional game roles. Now our players think it is too monotonous. All roles in the same profession are long. You should allow us to modify the role appearance when creating a role. For example, select the hair color.

What can we do with this? We have four occupations, each of which provides three colors of hair. We have to create another 12 sub-classes, in addition, the four implementation classes previously designed have little effect, because everyone must change the hair color. Well, write it with your scalp.

Public class WorriorWithRedHair implements Avatar {@ Override public String describe () {return "warrior + red hair" ;}} public class WorriorWithGreenHair implements Avatar {@ Override public String describe () {return "warrior + green hair" ;}} public class WorriorWithBlueHair implements Avatar {@ Override public String describe () {return "warrior + blue hair ";}} public class MageWithRedHair implements Avatar {@ Override public String describe () {return "Mage + red hair" ;}} public class MageWithGreenHair implements Avatar {@ Override public String describe () {return "Mage + green hair" ;}} public class MageWithBlueHair implements Avatar {@ Override public String describe () {return "Mage + blue hair ";} public class HunterWithRedHair implements Avatar {@ Override public String describe () {return "Hunter + red hair" ;}} public class HunterWithGreenHair implements Avatar {@ Override public String describe () {return "Hunter + green hair" ;}} public class HunterWithBlueHair implements Avatar {@ Override public String describe () {return "Hunter + blue hair ";} public class WarLockWithRedHair implements Avatar {@ Override public String describe () {return "+" ;}} public class WarLockWithGreenHair implements Avatar {@ Override public String describe () {return "+ green hair" ;}} public class WarLockWithBlueHair implements Avatar {@ Override public String describe () {return" + blue hair ";}

Now, I have finished working overtime until midnight. The next day at work, the boss came to you. Now there are more and more players. They reflect that our role is still too monotonous. We also need to allow players to choose the coat color and pants color, the coat has 5 colors and the trousers have 5 colors. After hearing this demand, I think you should also vomit blood. For example, Player A selects warrior + red hair + white shirt + blue pants, and player B selects + blue hair + white shirt + yellow pants. There are too many combinations, and how many implementation classes must be written. This method certainly does not work.

How can I solve the problem using the decorator mode?

At this moment, the company came up with a big bull. He heard about this situation and took over the demand. You thought he was crazy, but the next day he finished the task and you were shocked, hurry up and see how his code is implemented. The Daniel used the decorator design pattern that you didn't even hear.

First, he designed a class, implemented the Avatar interface, and passed in an Avatar object, which corresponds to the Decorator in the UML diagram.

public class AvatarDecorator implements Avatar {    private Avatar av;    public AvatarDecorator(Avatar avatar){        av = avatar;    }    @Override    public String describe() {        return av.describe();    }}

We can see that it holds an Avatar type object. In the describe method, we actually call the av describe object. The passed Avatar object is the object we need to decorate.

Well, now let's design hair color decorations first.

Public class RedHair extends AvatarDecorator {public RedHair (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ red hair";} public class GreenHair extends AvatarDecorator {public GreenHair (Avatar avatar) {super (avatar);} @ Override public String describe () {return super. describe () + "+ green hair" ;}} public class BlueHair extends AvatarDecorator {public BlueHair (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ blue hair ";}}

We can see that our constructor is the constructor of super () called, that is, the constructor of AvatarDecorator called. Our describe also calls super first. describe () is followed by our Decoration content. That is to say, an Avatar object we passed in is decorated by us. This is equivalent to ConcreteDecorator in UML.

Now, if a player wants to create a role, it can be created in this way.

// Red hair warrior Avatar avatar1 = new RedHair (new Worrior (); // green hair lock Avatar avatar2 = new GreenHair (new WarLock ());

Next, we will design a coat and trousers decoration class.

Public class WhiteJacket extends AvatarDecorator {public WhiteJacket (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ white coat" ;}} public class RedJacket extends AvatarDecorator {public RedJacket (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ red coat" ;}} public class BlackJacket extends AvatarDecorator {public BlackJacket (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ black coat" ;}} public class GreenJacket extends AvatarDecorator {public GreenJacket (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ green coat" ;}} public class BlueJacket extends AvatarDecorator {public BlueJacket (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ blue coat ";}}

Public class WhitePants extends AvatarDecorator {public WhitePants (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ white pants" ;}} public class BlackPants extends AvatarDecorator {public BlackPants (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ black pants" ;}} public class RedPants extends AvatarDecorator {public RedPants (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ red pants" ;}} public class GreenPants extends AvatarDecorator {public GreenPants (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ green pants" ;}} public class BluePants extends AvatarDecorator {public BluePants (Avatar avatar) {super (avatar) ;}@ Override public String describe () {return super. describe () + "+ blue pants ";}}

Now, we can combine our roles as needed.

// Green hair hunters wear white jackets and black pants Avatar avatar3 = new GreenHair (new WhiteJacket (new BlackPants (new Hunter ()))); // The Red Hair Mage wears a red coat and white pants Avatar avatar4 = new RedHair (new RedJacket (new WhitePants (new Mage ())));

Images and truth