Go PHP inheritance also requires a dominant gene

Source: http://www.phpchina.com/portal.php?mod=view&aid=40048

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:

1<?PHP2     classA3         { 4           protected Static $var 1=NULL; 5            Public Static functionTest ()6           { 7              EchoGet_called_class (). ' ‘.Static::$var 1.‘‘; 8           } 9         } Ten     classBextendsA One         {  A           protected Static $var 1= ' B ';  -         }  -     classCextendsA the         {  -           protected Static $var 1= ' C ';  -         }  -B::test (); b b +C::test (); C C -?>

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:

1<?PHP2  protected Static $var 1=NULL; 3   protected Static $var 2=NULL; 4    Public Static functionTest ()5   { 6      if(!Static::$var 2)7      { 8           Static::$var 2=Static::$var 1; 9      } Ten      EchoGet_called_class (). ' ‘.Static::$var 2.‘‘;  One   }  A }  -  - classBextendsA the {  -   protected Static $var 1= ' B ';  - }  -  + classCextendsA - {  +   protected Static $var 1= ' C ';  A }  at  -B::test (); b b -C::test (); 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:

1<?PHP2 classA3 { 4   protected Static $var 1=NULL; 5   protected Static $var 2=NULL; 6    Public Static functionTest ()7   { 8      if(!Static::$var 2){ 9           Static::$var 2=Static::$var 1; Ten      }  One      EchoGet_called_class (). ' ‘.Static::$var 2.‘‘;  A   }  - }  - classBextendsA the {  -   protected Static $var 1= ' B ';  -   protected Static $var 2=NULL;  - }  + classCextendsA - {  +   protected Static $var 1= ' C ';  A   protected Static $var 2=NULL;  at }  -B::test (); b b -C::test (); 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.

Go PHP inheritance also requires a dominant gene