Object-oriented Yangcun sports meeting continued

ArticleDirectory

• Next, let's think about it.

The previous article describes the process of object-oriented modeling in Yangcun games.Use the bottom-up method, Analysis summarizes some common mistakes. This article goes onDiscuss issues that will be made from top to bottom.

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.

The same scenario as the previous one, except that some classes at the underlying level are not refined, but higher-level classes. For example, to abstract animals directly, the methods for animals are as follows:

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

Public void run (){}
}
}

 

The game class is used to represent the sports meeting. The game class should have two typical behaviors, such as registration before the competition and start of the sports meeting.

Namespace gameapplication
{
Class game
{
Private list <animal> players;
// Register before the competition
Public void register ()
{
}
// Start the competition
Public void start ()
{
}
}
}

The above register and start have no specific implementation.

Next, let's think about it.

The registration register before the competition is mainly for contestants to register, so it is equivalent to creating an animal object instance in player and then adding it to the list.

// Register before the competition
Public void register ()
{
Animal player1 = new animal ();
Player1.name = "Pleasant goat ";
Players. Add (player1 );

Animal player2 = new animal ();
Player2.name = "gray Taro ";
Players. Add (player2 );

Animal player3 = new animal ();
Player3.name = "Robot goat ";
Players. Add (player3 );
}

Without looking at the problem above, we will continue to implement the start method of the game class.

// Start the competition
Public void start ()
{
Foreach (animal player in players)
{
??????
}
}

When implementing the start method, it is like the above, and I don't know how to write it. At this time, I was thinking: Is it true that the behavior of animals can be expressed by judging the name? I think this method is definitely not good, because I have learned the lessons of the previous article, you cannot use a switch to determine the type and then determine the object behavior. In addition, it is wrong to determine the behavior of an object by determining the property. In addition, the object type is also part of the object property.

The village chief said, "the behavior of checking the method in the previous article should be the responsibility of the object instance. That is, you must be brave enough to take responsibility"

Pleasant goat is smart, and the following is a prompt.CodeAnd relieved.

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

In the start method of game, the control is handed over to the player, and the player is an animal object instance. So let's look at the animal code.

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

Public void run ()
{
}
}
}

Here, the run method of the animal class has nothing to do.

Then I want ....

Here, we certainly cannot switch between different actions by determining the name. The person next to me came up with an idea that I have seen a lotProgramYou like to add a type to the class. You also add a class named animaltype to this program, and then the run of animal calls the call of animaltype.

Namespace gameapplication
{
Class animaltype
{
Public void run ()
{}
}
}

Then I want...

How can we determine object behavior through attributes ???

This problem falls into an obvious Strange Circle of thinking, and is another question about the problem. Is it true that we can only adopt the bottom-up method for Object Modeling implementation, rather than the top-down method.

In fact, the above is also a problem that often occurs-adding a type to a class, such as adding an animaltype to the animal, so that we can achieve it with luck.

Looking back, since adding an animaltype to the animal class cannot solve the problem, add the following sub-classes of the contestants, sheep, robotsheep, and Wolf, and change animal to an abstract class, the subclass method can achieve the effect of the previous article. In fact, the results are the same.

 

This article is based on the thinking of the previous article, that is, we must be able to analyze and implement from the bottom up, but also to analyze and implement from the top down.

the following article discusses the general problems of the two articles, "Simple programs" also mentioned that if more animals come to the competition, there will be many sub-classes that will lead to class explosion.