Object-oriented Yangcun games

ArticleDirectory

• Scenario Analysis
• Scenario implementation
• Scenario reconstruction 1
• Scenario reconstruction 2
• Solution

This article mainly describes how to use the object-oriented method to model and implement specific scenarios.Program. It also demonstrates the Iterative Modeling process, the obvious mistakes made during the process, and how to solve these problems.

Yangcun will hold an animal sports meeting. Pleasant goat, lazy goat, gray Taro, and robot goat will all be registered for the competition. The competition rule is who can reach the final point as soon as possible to win. After the race started, everyone was making a huge strides forward. After the beginning, only the robot goat is still preparing to see what the robot goat is preparing. It turns out that the robot goat can be transformed into an electric car and the robot goat will drive the car. At this time, gray Taro wants to do the same. He will go home immediately to move his plane and fly it. At this moment, the lazy goat is right to the pleasant goat. Let's stop running and catch up with them. It's better to go to bed. Like pleasant goat, they drive an electric car and a plane, and I have the skill of Sun Wukong to win them. Suddenly, there was no rule that I could not go straight to the end point, that is, if I did not move forward, but instead came back to the end point (Here we assume that the start point and the end point are together), then I would have to go first.

 

Scenario Analysis

When analyzing this scenario, we found that it was really "The Eight Immortals passed through the sea, and they showed their magical powers ". It is basically possible to think of a goat as a kind. Here it can include pleasant goat, blue goat, and robot goat. Gray Taro is also classified as one type. We can see that such a classification is based on biological classification. The following class diagram can be obtained.

First, let's take a look at our previous story and extract behavior from it. For example, the robot goat runs an electric car. Pleasant goat arrived at the destination, while gray Taro flew. At this time, it was found that the robot goat was also a sheep, but his behavior was inconsistent. Therefore, a subclass of the robot goat was added to the goat. Then add actions to these animals.

Namespace gameapplication
{
Class animal
{
Public string name {Get; set ;}
}
}

Namespace gameapplication
{
Class sheep: Animal
{
// Pleasant goat is directed to the destination
Public void back ()
{
Console. writeline ("Pleasant goat directly to the end ");
}
}
}

Namespace gameapplication
{
Class Wolf: Animal
{
// Gray Taro is flying
Public void fly ()
{
Console. writeline ("gray Taro is flying ");
}
}
}

Namespace gameapplication
{
Class robotsheep: sheep
{
// The robot goat runs an electric car.
Public void drive ()
{
}
}
}

Scenario implementation

Create a games game and implement register and start.

Using system;
Using system. Collections. Generic;
Using system. LINQ;
Using system. text;

Namespace gameapplication
{
Class game
{
Private list <animal> players;

Public void register ()
{
Players = new list <animal> ();

// Pleasant goat and lazy goat
Sheep player1 = new sheep ();
Player1.name = "Pleasant goat ";
Players. Add (player1 );

Sheep player2 = new sheep ();
Player1.name = "lazy goat ";
Players. Add (player2 );

// Robot goat
Robotsheep player3 = new robotsheep ();
Player3.name = "Robot goat ";
Players. Add (player1 );

// Gray Taro
Wolf player4 = new wolf ();
Player4.name = "gray Taro ";
Players. Add (player4 );
}

// The key issue is here
Public void start ()
{
Foreach (animal player in players)
{
Type type = player. GetType ();
Switch (type. tostring ())
{
Case "gameapplication. Sheep ":
Sheep sheep = player as sheep;
Sheep. Back ();
Break;
Case "gameapplication. robotsheep ":
Robotsheep = player as robotsheep;
Robotsheep. Drive ();
Break;
Case "gameapplication. Wolf ":
Wolf wolf = player as wolf;
Wolf. Fly ();
Break;
Default:
Break;
}
}
}
}
}

Run the program and see the following result.

Pleasant goat goes directly to the destination
Pleasant goat goes directly to the destination
Robot goat runs an electric car.
Gray Taro is flying

Basically, the result is normal. Next we need to improve the current program implementation. Some people say that if you refactor start, so many switches may be faulty.

Scenario reconstruction 1

Now let's change the start method in game to determine the type of game, and then call different behavior interfaces to define them in the corresponding type.

Public void start ()
{
Foreach (animal player in players)
{
Player. Run ();
}
}

The above start method looks a lot more beautiful, simple and direct. Next, let's take a look at how the goat, machine goat, and gray Taro classes are implemented.

Namespace gameapplication
{
Class sheep: Animal
{
// Pleasant goat goes directly to the destination
Public void back ()
{
Console. writeline ("Pleasant goat directly to the end ");
}

Public override void run ()
{
Back ();
}
}
}

Namespace gameapplication
{
Class robotsheep: sheep
{
// The robot goat runs an electric car.
Public void drive ()
{
Console. writeline ("Robot goat is an electric car ");
}

Public override void run ()
{
// Base. Run ();
Drive ();
}
}
}

Namespace gameapplication
{
Class Wolf: Animal
{
// Gray Taro is flying
Public void fly ()
{
Console. writeline ("gray Taro is flying ");
}

Public override void run ()
{
Fly ();
}
}
}

Sure enough, the world is quiet a lot. Let's take a look at the implementation of machine sheep.

Namespace gameapplication
{
Class robotsheep: sheep
{
// The robot goat runs an electric car.
Public void drive ()
{
Console. writeline ("Robot goat is an electric car ");
}

Public override void run ()
{
// Base. Run ();
Drive ();
}
}
}

Note that the bold part // base. Run () overwrites the parent class because it violatesLee's principles(That is, subclass should not overwrite the implementation of the parent class, but should be extended ). Some people will ask, if this is not the case, how can this problem be achieved? Indeed, the current structure determines that the implementation of the parent class can only be overwritten in violation of principles.

Scenario reconstruction 2

Now that there is a problem, let's take a look at the problem. For a long time, it turns out that it is wrong to use the robot goat as a subclass of the goat!

Assuming that the robot goat and the goat are inherited, the robot goat should completely comply with the behavior of the goat, but the robot goat does not, so the behavior is different in the scene, even biological classification also requires the creation of a new category rather than inheritance, not to mention that the robot goat is not necessarily a race of the goat.

If the problem is found, we can change the structure and implementation of the robot goat.

Namespace gameapplication
{
Class robotsheep: Animal
{
// The robot goat runs an electric car.
Public void drive ()
{
Console. writeline ("Robot goat is an electric car ");
}

Public override void run ()
{
Drive ();
}
}
}

 

After the above modification, the robot goat does not violate the object-oriented principle of the river. In addition, the program running is consistent with the above results.

Then let's take a look at the problem. All of our animal-type run behaviors call our own electric vehicles and fly planes. Why does this happen.

It is mainly because abstract animals do not have good abstract behaviors in the race. That is to say, we only pay attention to the particularity of the individual, but do not abstract the general nature of the whole, which will lead to a lot of mistakes.

 

Solution

Next, let's take a look at the small mistakes made in modeling from the above examples. However, this is because of this small mistake that we can get a really object-oriented program after constantly modifying it.

Problem type 1: I always like to judge the object type and then interact with the object based on the type.

The preceding switch statement is used in this example.

Solution: Make sure that the object has a class but no type. That is, you can define a class for the object, but do not pay attention to the object type when operating the object instance of this class. Only in this way can we be truly object-oriented. This is also the most basic and common problem of many object-oriented programs.

Problem type 2: category error causes the subclass to overwrite the behavior of the parent class

In this example, the machine sheep is a child of the goat.

Solution: the Child class of the parent class should establish another class parallel to the parent class.We often make this mistake, and we like subclass to overwrite the behavior of the parent class.

 

In fact, the root cause of the problem is that the object-oriented abstraction is not well understood. In the abstract process, we may focus too much on the object type structure, such as how to inherit, rather than the abstraction of object behavior. If we abstract pleasant goat, robot goat, and gray Taro to drive an electric car and airplane, and abstract them into a race in one step, then there will be no machine goat electric car driving method, gray Taro's method of flying the plane. That is, in the abstract process, the characteristics and commonalities are abstracted, but the individual details are often concerned. When running the program, the system pays too much attention to the object type, which leads to the need to check the object type.

In a word, the object orientation is abstracted first. What the outside sees for this abstract class is commonalities. The object focuses on its own personality and has different implementation methods. In interaction with external objects, external objects do not attempt to know how the object is done internally. You only need to tell the internal object what you want to do, and then the internal objects exert their own personality, this is the object-oriented encapsulation mechanism.

We can also see the different embodiment of object-oriented abstraction and encapsulation. abstraction is a static process, that is, focusing on definition. encapsulation is particularly good at runtime, this frees external users from paying attention to their own implementations.

The subsequent articles will focus on encapsulation.