A simple attempt of the Mode

Many people asked me if the teacher had learnedProgramCan it be a world of warcraft? Well, how can we answer that. World of Warcraft has been playing, and the 3C competition has always paid the highest attention. Blizzard often engaged in some high-reward competitions in business operations to attract the attention of the audience. But I am also thinking about this question. What should I do if I want to be a Warcraft game? Let's take a look at how to design farmers.

First, we will think that farmers should have several basic functions:
Display -- display appearance
Excavate-collection and mining
Move -- move
Stop -- stop moving
In this way, we can design an abstract class, but the display method also needs to be set to abstract, because we want to set human, beast, and fairy) the appearance of a farmer is different from that of an undeath. It must be implemented separately.

Figure 1

Suddenly I think of a problem. Farmers should join the basic attack capability-Attack! It is easy to implement: we can add this method to the base class. However, there is a problem. In this way, fairy also has the ability to attack, so it cannot, because in fact, fairy cannot attack! Yes, it is a problem to use the class inheritance method. Once you want to add some features to the base class, Its Derived classes also have new features. This is OK, and simple improvements affect the global. However, subclasses that do not have this function are not spared the addition of new functions.

Public abstract class farmer
{

Public void excavate (){}

Public void move (){}

Public void stop (){}

/// <Summary>
/// Display
/// </Summary>
/// <Remarks> display appearance </remarks>
Abstract Public void display ();

Public Virtual void attack ()
{
Console. writeline ("fire! Attack U !");
}
}
Of course, we can override this method in the subclass.
Public class FAIRY: farmer
{
Public override void display ()
{
Console. writeline ("fariy :.......");
}

Public override void attack (){
// No more
}
}

This is the case, but we have sniffed the problem:
1. Maybe we will add other races for the development of the game in the future. Maybe the farmers of that race cannot have the attack method, and we need to rewrite it.
2. More importantly, now we have added the attack method, and many other methods may be added, but this method cannot appear in all subclasses.
To put it bluntly, using inheritance cannot solve the problem well, because the actions of farmers are constantly changing in subclass and it is inappropriate for all subclasses to have such actions.

Identify potential changes in applications and separate them from those that do not need to be changed.Code. The idea of "encapsulating changes" is almost the spirit behind every design pattern.

All right, the thing we need to change here is attack, which does not exist with every class. Okay, independent! In addition, we need to make the attack behavior dynamically change. What should we do? All we need is an attack. We don't care how to attack it. So we extract attack and define it as an interface:
Interface iattackbehavior
{
Void attack ();
}
In the base class, we must use the reference of this interface:
Public abstract class farmer
{
Internal iattackbehavior attackbehavior;

Public void attack ()
{
Attackbehavior. Attack ();
}
 
......
 
}

As for how to launch an attack, you only need to implement this interface. For example, we will first implement two actions: attacking with weapons and not attacking.

Figure 2

/// <Summary>
/// Attack with weapons
/// </Summary>
Class attackwithweapon: iattackbehavior
{
# Region iattackbehavior Member

Public void attack ()
{
Console. writeline ("hey, fire! Attack !!!");
}

# Endregion
}
/// <Summary>
/// No attack
/// </Summary>
Class noattack: iattackbehavior
{
# Region iattackbehavior Member

Public void attack ()
{
Console. writeline ("I can not attack U! But I can burn your power !");
}

# Endregion
}
This idea is not only for interface programming, but also for implementation programming.

Now, let's modify the attacking behavior of the genie (fairy). It cannot attack, so we can achieve the class of behavior that cannot attack:
Public class FAIRY: farmer
{
Public fairy ()
{
Base. attackbehavior = new noattack ();
}

Public override void display ()
{
Console. writeline ("fariy :.......");
}
}
However, the peasants of the people family use a hacker to attack:
Public class human: farmer
{
Public Human ()
{
Base. attackbehavior = new attackwithweapon ();
}

Public override void display ()
{
Console. writeline ("Human: Work work .");
}
}
The same principle applies to beasts:
Public class BEAST: farmer
{
Public beast ()
{
Base. attackbehavior = new attackwithweapon ();
}

Public override void display ()
{
Console. writeline ("BEAST: Ooo ~~~ Right ");
}
}
A problem is suddenly found here. The peasants who are not dead are attacking by hand! Well, here we can see the benefits of applying the pattern after refactoring the code. We can implement another hand attack:
Class attackwithoutweapon: iattackbehavior
{
# Region iattackbehavior Member

Public void attack ()
{
Console. writeline ("Haha, beat !!!");
}

# Endregion
}
Well, now, we can attack farmers who are not dead!
Public class undeath: farmer
{
Public undeath ()
{
Base. attackbehavior = new attackwithoutweapon ();
}

Public override void display ()
{
Console. writeline ("undeath: some more .");
}
}

Let's take a look:
Public static void main ()
{
Console. writeline ("hello, design patterns >>>> \ r \ n ");

Human H = new human ();
H. Display ();
H. Attack ();

Beast B = new beast ();
B. Display ();
B. Attack ();

Fairy F = new fairy ();
F. Display ();
F. Attack ();

Undeath u = new undeath ();
U. Display ();
U. Attack ();
Console. Read ();
}

What is the final result:
Hello, design patterns >>>

Human: work.
Hey, fire! Attack !!!
BEAST: Ooo ~~~ Right
Hey, fire! Attack !!!
Fariy :.......
I can not attack U! But I can burn your power!
Undeath: some more.
Haha, beat !!!

Haha, it's really good.

Figure 3

What if we want to add another race? What if farmers of the new race have special requirements for attack? What changes should we make? Is it very difficult?
Wow, after refactoring the Code, these requirements won't modify all our previous code, just add new classes and behavior implementations! So cool !!!