About the things that PHP inherits, my personal insights, PHP inherits those things insights _php tutorials

To talk about the things that PHP inherits, my personal opinion, PHP inherits those things insights

On the internet often spread out the lowest end of the language, PHP is the one, once the University of Java, bi-set with Java, just out of training with Java I, in the initial work of 2, 3 years when the object of PHP is also quite opinion, always feel "nondescript", not to mention the view of JS. But these ideas have been gradually diluted and even changed after more and more projects. Here the bread with its own on the project, technology has more understanding, and in these years, the Web environment, technology is constantly updated. But today is not to talk about these things, for the above questions, my view can be summed up as: technology is a tool, means, not appropriate to upgrade, change, it is so simple.

Words to the original question. Although writing PHP has been nearly 8 years of foundation, but because of the working relationship, often need to involve the front and back of the various code, easy to fine points, also always remember. One of the things that happened recently made me feel that maybe writing down can make me sober.

A static member is used to write a module in a certain year, and in the process of implementing the subclass, it is found that they also share the value of the member of the parent class, specifically, I changed that member value in a subclass a, and when the other subclass B was used, the result unexpectedly got the value after a. It was thought that the original static member was shared across the entire category tree from where it was declared. Later, I vaguely remember this conclusion, using static members more cautiously in the usual code, unless it is not easy to use static if the class being written is a standalone tool class.

Until one day my eldest brother and I discussed the upgrade of a Basemodel I wrote earlier, he inadvertently asked me: as if you do not like to use static members? I said no, because considering the Basemodel will be often inherited into a variety of model, if I use static here, it will be easy to step on the pit. He did not understand, and then came and debated with me. I'm very righteous. The value of the static member's variable is as uncontrolled as a global variable, because the static member is shared and if two different subclasses are to be called. He did not agree. So in the spirit of science, we wrote a short code to verify:

Class A {

protected static $var 1 = null;

public static function test () {

Echo Get_called_class (). ". Static:: $var 1. '
';

}

}

Class B extends A {

protected static $var 1 = ' B ';

}

Class C extends A {

protected static $var 1 = ' C ';

}

B::test ();

C::test ();

Obviously, this time I was defeated. The result I am looking for is C C, but in fact it is b C. Then it seems that the static members of the subclass are shared only at the level of the child class. But I always feel that something is wrong, obviously in writing basemodel when I have fallen again, why this verification does not support me at that time encountered problems? So I found that I was in a split. How nice young. Then I thought, the reason why I don't need static here is simply because of the design needs.

I thought I was wrong. Until a few days ago wrote a few father and son class (not Basemodel), bold use of static members, the result is vigorous in the self-test and fell a fall. What's going on! Then I took a closer look at my own usage and changed the example above to run:

Class A {

protected static $var 1 = null;

protected static $var 2 = null;

public static function test () {

if (! Static:: $var 2) {

Static:: $var 2 = static:: $var 1;

}

Echo Get_called_class (). ". Static:: $var 1. '
';

}

}

Class B extends A {

protected static $var 1 = ' B ';

}

Class C extends A {

protected static $var 1 = ' C ';

}

B::test ();

C::test ();

The result is

b b

C b

If the last conclusion is right, then how to explain this time? Here is clearly to indicate that $VAR2 is a,b,c shared. The difference between the $var 1 and $var2 seems to be just a statement and an undeclared distinction. So I changed it again:

Class A {

protected static $var 1 = null;

protected static $var 2 = null;

public static function test () {

if (! Static:: $var 2) {

Static:: $var 2 = static:: $var 1;

}

Echo Get_called_class (). ". Static:: $var 1. '
';

}

}

Class B extends A {

protected static $var 1 = ' B ';

protected static $var 2 = null;

}

Class C extends A {

protected static $var 1 = ' C ';

protected static $var 2 = null;

}

B::test ();

C::test ();

The result is

b b

C C

I was in a broken heart. So I went to stack Overflow and found that I was not the only one in the pit.

Only static members that are explicitly declared are considered to be subordinate only to subclasses.

Only static members that are explicitly declared are considered to be subordinate only to subclasses.

Only static members that are explicitly declared are considered to be subordinate only to subclasses.

Important thing to say three times! However, if there are a lot of subclasses, the members of the dynamically determined value each declare it, and lose the meaning of static in writing the code. A better approach is to change the $var2 into an array, with the values of each class being used in the $var[__class__].

But anyway, if it's not necessary, try not to inherit from the static member.

There is also a sort of "pit". When we talk about private members, we all know that private is a proprietary, not a quilt class inheritance. But sometimes when you write code, you forget that it's not until you take a fall to remember that the original is private so that the subclass cannot find the member, or private is declared in the subclass, but because calling the function is called the parent class function, the result is that the parent class is the private value instead of the subclass. In this case, it is impossible to rewrite the function as it is in the subclass. So use private to be very careful.

Once, when using the SDK of Rackspace, I saw that some classes used private members, but because they gave unnecessary open file permissions, the code could not run on our server. So this time I want to write a sub-class covering up the initial value of this member, the result is because it is a private member, and finally need to copy all the references to their own sub-class written. Why don't we just change the SDK so that members become protected? Because the development package might be upgraded next time? It would be nice to remove the class after the fix. If you modify the library code become a habit, want to upgrade the time is not so happy. Therefore, the use of private members must be cautious, if you are also developing the SDK, you need to consider whether users need to inherit? If you had to write private, would you be able to guarantee that the code could adapt to the use of various scenarios?

Unless you have a very good reason, both static and private need to be used carefully.

http://www.bkjia.com/PHPjc/1138823.html www.bkjia.com true http://www.bkjia.com/PHPjc/1138823.html techarticle To talk about the PHP inheritance of those things, my personal opinion, PHP inherited those things on the internet often spread out PHP is the language despise the lowest end of the chain, once the University of Java, BI set with Java, just out ...

