"Object-based" and "object-oriented"

Some netizens asked a small question about "Vernacular C ++" about virtual functions and Polymorphism:

"If a virtual function is used to make the object of a derived class have a special and different personality. Define the heap variable of a base class, but instantiate the heap variable using the derived class:

Code:

1. Person * someone;
2. Someone = new beauty;
   

What is the purpose? What are the benefits? In this case, why not instantiate the base class and derived class objects separately? "

Let's take a simple look:

It is also common to instantiate base classes and derived classes separately. this is usually called ob programming ("Object-based"). In this case, the derived classes and the base classes are specific things, only the derived class expands the function of the base class ...... however, in the OO method, abstraction is very important. the so-called abstraction and specifics are usually: The base class represents "abstraction", and the derived class represents "concrete ". for example, the basic category is: Flying Object (abstraction )... derived class: Airplane, e .... (Specific, or concrete ). if you want to write a program for a flying object, we certainly want to write the shooting logic only once for the "Flying Object", rather than for a variety of derived classes.

As an abstract class, a base class only requires that: "What functions must my Derived classes provide?"-This is exactly what the category represents. We occasionally scold others: "You are simply not a person ". Why? This is because, in some societies, the Public Morality stipulates the "functions" that "humans" should possess. If a person is put aside by society, it must be:

1) I did something that is not within the scope of human functionality. (For example, he has some functions that only animals have ).

2) some functions that humans must possess are missing. (For example, kindness. As an object, he finds that he does not have this function)

Back to the flight object example. In flying thing shooting games, it usually requires:

1. Can Fly (or how can it be called a flying thing )?

2. Can I determine if I am hit?

3. Some responses should be made after being attacked.

4. If you are attacked, but you are not in the middle of the attack, try to make a response ......

Code:

1. Class flyer // not a fly
   
2. {
3. Public:
4. Virtual void flying () = 0; // I can fly
5. Virtual bool hittest (int x, int y, bullet const & bullet) = 0; // is it hit by a bullet?
6. Virtual void onhitted () = 0; // What if it is hit?
7. Virtual void onescape () = 0; // What if it is out of date?
8. };

Okay. Admit that this abstraction may not be well written. For example, the hittest function may not require X or Y, but the bullet will provide its own location ...... In addition, the function of how a flying object draws a screen is not provided ...... However, these are not the key points. The point is that this is a good abstraction, so it is all "= 0" pure virtual functions-representing that flyer only provides requirements, all specific actions or functions need to be implemented by a derived class.

But what do Derived classes have? The theory is endless! The creator of the game, assuming you are the only one, may write it as one:

Code:

1. Class airplane: Public flyer
3. {
5. // Implementation
7. };

There is only one shooting target for airplanes, so this game may only be called the "airplane" game ...... But your boss is ambitious! It turned out that this game was a big sale. However, thanks to your outstanding talent, you were bought by M $ with honor, so another programmer came up to fill your gaps. If it was me, I thought it was not fun to fly alone, it is better to add a lower difficulty coefficient, so I write a derived class:

Code:

1. Class Duck: Public flyer // do not take a duck as a flying object
2. {
3. //...
4. Virtual void onhitted () // hit
5. {
6. Cout <"Ga ~~ Ga ~~~ "<Endl; // The actual code is output to the sound card.
   
7. //....
8. }
10. };

Now the question is coming! My predecessor (you) did not know that someone would write a "Duck" derived class, but one day, I will also leave (I really want to go to Google ~~ 555) What are the derived classes written by my sequencer? I don't know. It's a UFO.

The typical problem here is: do later programmers have to modify the code of their predecessors in depth? For Bo, this is very likely. But for oo, this can be effectively mitigated, because oo programmers, he knows (STRIVE) to write only the main logic in the code for "abstract" objects, such as a bullet flying out, at this time, the full screen flying object, my great predecessor, the great oo programmer, once again stressed that you are writing this logic like this:

Code:

1. ...
3. STD: List <flyer *> flyerlst; // a list Of all flying objects on the current screen
5. Bullet bullet; // a flying bullet...
7. ...
9. STD: List <flyer *>: iterator it; // list iterator. For details, refer to "Hello STL ".
11. For (IT = flyerlst. Begin (); it! = Flyerlst. End (); ++ it)
13. {
15. // The focus is here:
17. Flyer * flyer = * it; // to be clear, I'm a bit wordy.
19. If (flyer-> hittest (bullet) // determines if a hit is detected?
21. {
23. Flyer-> onhittest (); // If flyer is a duck object, it will be gaga called ~~~
25. //....
27. }
29. }

Look, the above Code is what you wrote at the time. It is always there and only processes the flyer object! No duck or UFO words, right?

Successor, me, just put my duck in the list ......

Code:

1. Flyer * flyer = new duck; // it doesn't matter here. You can also write duck * duck = new duck;
2. // If possible ......
4. Flyerlst. push_back (flyer );

As a predecessor, you don't need to know anything specific about duck ...... And UFO ......

--------------------

I thought I already talked about it in "Vernacular C ++. When it comes to new, that is, "But possible" in the above Code, why should we write it like this;

Flyer * flyer = new duck;

This depends on the situation. When we can directly know which object is being created and need to make specific settings for the derived class, it is necessary to write clearly. Imagine that when the duck succeeds in dodge bullets, it may get an egg due to nervousness. Then the player can hit the duck eggs to earn points. However, ducks are differentiated from male, and not all female ducks can lay eggs (developmental problems ). Therefore, after creating a duck, we need to call a function to try to prepare the inventory of eggs.

Code:

1. Duck * duck = new duck;
3. Duck-> prepareeggs (); // maybe only ducks need to prepare eggs.
5. Flyerlst. push_back (duck );

In this case, it is called "specific analysis of specific things". Give it to the derived class. If the base class pointer representing the abstraction is used, the Code cannot be compiled, isn't it? Because not all flying objects have function.

Code:

1. Flyer * flyer = new duck;
3. Flyer-> prepareeggs (); // compilation error! The flyer class does not have this function.
   

 

But you cannot leave the problem blank! Is it true that only a duck can get something done? When an airplane evades bullets, will the (enemy pilot) be angry and drop some bombs? Well, isn't UFO dropping a few aliens? To make the game scalable, this pre-designed elasticity is necessary. So let's make another change and abstract the specific thing "drop eggs" into "throwing things "!

Code:

1. Class flyer
3. {
5. //... Original omitted
7. Virtual void throwobject () = 0; // throw something
9. Virtual void preareobject () = 0; // prepare the inventory
11. };

What a wonderful design (a normal programmer's self YY )! What we can do now is not just create a duck, but also prepare a duck egg. We can meet this requirement: When a flying object stays in the sky for a certain period of time, it can automatically call prepareobject to prepare the inventory, and then when the appropriate time, it will pass throwobject () drop all kinds of things! In this way, players need to be smarter. For example, they can keep the ducks alive for a while, because we want the eggs, and the plane will not be able to survive. We must kill them quickly, otherwise, it will have more and more bombs ...... Maybe you are a game planner. At this time, you are actively designing these game logics. Maybe you are a programmer. At this time, you are forced to implement these logics, but good program design has no feelings, whether active or passive, the goal is to make complex, constantly evolving logic easier to implement and make programmers more comfortable. The corresponding and bad design is to make you, or you have a hard time renewing your team.

 

The third issue is also a key issue. A good oo designer certainly won't write fully ob code, but it doesn't have to (objectively) Abstract The functional interfaces of all objects. God has spent time creating ducks, so ducks always have independent lives-a temporary inspiration: God has created every one of us, so we always have our own uniqueness-these uniqueness is impossible, or not suitable for abstraction-continue to return to the subject, but even so, sometimes we still need to use the base class pointer to accept each unique derived class object.

 

Continue the game. Imagine that the flight object on the screen is continuously hit and dropped, and the program must be responsible for generating new flying objects to fly to the sky. How can we decide which flight object to generate? This is a policy. The strategy can be very simple. It is determined by a random number, but it is best to decide what to fly to the east and west Based on the difficulty and the number of points. We can write a function:

Code:

1. Flyer * createnewflyobject (); // an important function! It determines whether the strategy is good or bad.
2. // One of the important factors of "fun.

Although it is not directly in a new flying object, this function is actually a complicated new. It generates a Flyer through various judgments. What is this flyer? In a good design, the code at the call should not be concerned. The caller only needs to use the base class pointer to undertake:

Code:

1. Flyer * flyer = createnewflyobject ();

This line means (pseudo code): flyer * flyer = new dock ?? UFO? Airplane ?? What did it create! I think of them as flying objects! (The voice of an OO programmer ).

The conclusion is the same: we are always trying to make the key code only process the base class (abstract) as much as possible, rather than the derived class (concrete ).

 

Some readers want to ask questions, ...... It's actually an advertisement. If you don't have time, don't pull it down. :)

 

 

Someone asked, after reading "Vernacular C ++", will the above game be written?

A: No problem, because "Vernacular C ++" is not just about syntax (although the syntax content is the largest), it will also be based on the famous SDL, at least three mini games are explained. Some non-programming students wrote one of the games through their own extensions when they read only less than four points.

 

------------ Welcome to the publication of "Vernacular C ++ -------------------------

Busy with house ...... I haven't been here for a long time. It's okay for all of you ~~~ If you want to communicate with me, click the following link to become a friend:
Http://student.csdn.net/invite.php? U= 112600 & C = f635b3cf130f350c