StarCraft php object-oriented (2)-PHP development

The audience is very broad and profound. People who have never been in touch will feel confused. I learned a lot of materials, but most of them are abstract. So I used the classic game-Starcraft to discuss PHP object-oriented. Now let's assume that we are using PHP to develop Starcraft, so as to get in touch with PHP object-oriented. Note: In order to facilitate learning, except for special instructions, other codes are not associated. V. Access Control

If $ attackNumber = 10 is used to indicate the attribute, the default value is public $ attackNumber = 10. Therefore, we recommend that you write the attribute as follows:

Class marine {public static $ attackNumber = 10; // Number of attack power}

Public indicates that this attribute is public, that is, it can be accessed and operated anywhere.

But there are some problems. If a player knows some code structures like marine, then he will make a simple patch and load it during running:

// Patch marine: $ attackNumber = 10000;

In this case, his Gunshots have 10000 attack power. In this case, who beat him!

Therefore, we need to use private to indicate that this attribute can only be accessed by functions in the class:

Class marine {private static $ attackNumber = 10; // The number of attack power. // This function indicates the Running code function upgrade () {// to prevent unlimited upgrade if (self:: $ attacknum <13) {self: $ attacknum ++ ;}}}

In this way, only the upgrade can change the attacker's attack power.

But now it is often developed by teams, and many use class inheritance. If it is private, the subclass will not be accessible, but you do not want to modify some attributes at will.

You can use the protected and protected attributes to access functions of the quilt class.

Vi. Heavy Load

6.1. Attribute Overloading

If we take the ground troops as a class and let them inherit from the class, if the ground troops and the class have defined the attack force $ attackNumber, therefore, the attack power of each soldier is determined by the type of the host, rather than the ground. This is called overload.

// Class groundArmy {public $ attackNumber = 5;} // The class marine extends groundArmy {public $ attackNumber = 10; // Number of attack power} $ m1 = new marine (); // create a new host echo $ m1-> attackNumber; // display the attack power as 10

6.2 function Overloading

Overload can also be used for functions. If the subclass function has the same name as the parent function, unless otherwise specified, the subclass object calls the function in the subclass by default.

For example, ghost and dark holy Hall (hidden knives) of the gender are all invisible weapons, but they reduce energy when they are invisible, the dark holy Hall has no energy attribute at all.

If we take the stealth capability as the parent class, the ghost-type ghost and the dark holy Hall class DarkTemplar of the god family will inherit it, and at the same time implement different invisible code:

// Class concealAbility {// This function indicates the invisible Running code function conceal () {// invisible Running code }}// ghost soldier class ghost extends concealAbility {$ energy = 150; // This function indicates the invisible Running code function conceal () {// invisible Running code // reduce the ghost soldier's energy, $ this indicates the current object, that is, the current ghost soldier $ this-> energy-= 25 ;}} // dark holy Hall class DarkTemplar extends concealAbility {// This function indicates the invisible Running code function conceal () {// The Invisible Running code, no energy impact} // create a new ghost soldier $ g1 = new ghost (); // display the energy as 150 echo $ g1-> energy; // stealth $ g1-> conceal (); // The displayed energy is 125 echo $ g1-> energy; // create a new dark holy Hall $ d1 = new DarkTemplar (); // The Dark holy Hall is invisible. He has no energy attribute $ g1-> conceal ();

VII. Interface

PHP does not allow multiple inheritance, so some problems are hard to solve.

How can we deal with human reconnaissance planes if we establish a class of invisible capabilities and then put the flight capabilities in a class to standardize the processing? Two classes cannot be inherited!

We do not need to inherit the code, but should other developers read the long code once it involves reconnaissance planes? Is it possible to have a brief description of all methods of the class?

Interface interfaces can be used. A class can execute (inherit) Multiple Interfaces. the functions defined in the interface cannot have function bodies. The class that executes the interface must completely define these functions.

In this way, we know that the reconnaissance plane implements the flight capability interface, and there must be a flight method described in the interface:

// Interface concealAbility {public function conceal ();} // interface flyAbility {public function fly ();} // reconnaissance plane class Wraith implements flyAbility, concealAbility {// This function indicates the Running code of the reconnaissance plane flight function fly () {// flight Running code} // This function indicates the invisible Running code of the reconnaissance plane function conceal () {// invisible Running code }}

VIII. Summary

We have discussed the basic knowledge of PHP object-oriented. Through Starcraft, a classic game, we can see the initial role of object-oriented.

We can see that the object-oriented method can make the code clearer and the class organizes the Code to facilitate reuse.

At the same time, the object also reduces variable conflicts to facilitate the storage and use of correlated data.

If the problem to be solved involves many aspects, object-oriented methods can be developed to be more flexible and skillful, such as the design pattern and many frameworks.

Of course, object-oriented has some disadvantages. From the code above, we can see that there is more code first. If simple tasks define many classes, it is troublesome.

For simple tasks, object-oriented operations may also reduce code execution efficiency.

In-depth discussion is beyond the scope of this article.