Let's talk about what PHP inherits, my personal opinions, and my opinions on what php inherits.

Let's talk about what PHP inherits, my personal opinions, and my opinions on what php inherits.

Php is the lowest end of the language contempt chain that often flows out on the Internet. I used to study java in college and use java after I first came out to train me with java, in the first two or three years of work, I also had a lot of opinions on the php object-oriented architecture. I always thought that [nondescribedomains】, let alone my views on js. However, these ideas have been gradually diluted and even improved after more and more projects. Here, I have a better understanding of projects and technologies. At the same time, Web environments and technologies have been constantly updated over the years. However, I am not talking about these things today. My point of view on the above issues can be summarized as follows: technology is a tool and a means. If it is not suitable, upgrade and change.

Back to the original question. Although php has been written for nearly eight years, due to work relations, various front-end and back-end code is often required, so it is easy to score points and you will always be confused. One thing that happened recently made me feel that writing it down may help me stay awake.

When a module is written in a certain year, the static member is used. When the child classes are implemented, it is found that they share the value of the member of the parent class, specifically, I changed the member value in A subclass A. When another subclass B is used, the result accidentally gets the value after A is overwritten. At that time, I thought that the original static members were shared in the entire category tree starting from the Declaration. Later, I vaguely remembered this conclusion. In normal code, I was more cautious about using static members. Unless I confirmed that the written class is an independent tool class, I would not easily use static.

One day, my boss talked to me about upgrading a BaseModel I wrote before. He accidentally asked me: Do you like static members? I didn't say so, because considering that BaseModel is often inherited into various models, if I use static here, it will be easy to step on. He said he did not understand it, and then he came to debate with me. I am very happy to say that because static members will be shared, if you want to call two different subclasses, the variable value of the static member will be as uncontrollable as a global variable. He does not agree. So in the spirit of science, we wrote a short code to verify:

Class {

Protected static $ var1 = null;

Public static function test (){

Echo get_called_class (). ''. Static: $ var1. '<br/> ';

}

}

Class B extends {

Protected static $ var1 = 'B ';

}

Class C extends {

Protected static $ var1 = 'C ';

}

B: test ();

C: test ();

Obviously, this is my defeat. The expected result is c, but B c. In this case, it seems that the static members of the subclass are only shared at the subclass layer. However, I always felt that something was wrong. When I wrote the BaseModel, I had already followed suit. Why did this verification not support the problems I encountered at that time? So I found that I was confused. How young is it. Later I thought about it. The reason why I didn't need static here was just because of the design requirements.

I thought I was wrong. I wrote several Parent and Child classes (not BaseModel) a few days ago, and boldly used static members. The result was that I fell down again in self-testing. What's going on! Then I paid close attention to my usage and changed the above example to run it:

Class {

Protected static $ var1 = null;

Protected static $ var2 = null;

Public static function test (){

If (! Static: $ var2 ){

Static: $ var2 = static: $ var1;

}

Echo get_called_class (). ''. Static: $ var1. '<br/> ';

}

}

Class B extends {

Protected static $ var1 = 'B ';

}

Class C extends {

Protected static $ var1 = 'C ';

}

B: test ();

C: test ();

The result is

B B

C B

If the last conclusion is correct, how can this time be explained? $ Var2 is shared by A, B, and C. The difference between $ var1 and $ var2 seems to be only a distinction between voice and no declaration. So I changed it to the following:

Class {

Protected static $ var1 = null;

Protected static $ var2 = null;

Public static function test (){

If (! Static: $ var2 ){

Static: $ var2 = static: $ var1;

}

Echo get_called_class (). ''. Static: $ var1. '<br/> ';

}

}

Class B extends {

Protected static $ var1 = 'B ';

Protected static $ var2 = null;

}

Class C extends {

Protected static $ var1 = 'C ';

Protected static $ var2 = null;

}

B: test ();

C: test ();

The result is

B B

C c

I collapsed at the time. So I went to Stack Overflow and found that I had more than one trap.

Only explicitly declared static members are considered to be sub-classes only.

Only explicitly declared static members are considered to be sub-classes only.

Only explicitly declared static members are considered to be sub-classes only.

The important thing is said three times! However, if there are many sub-classes, every Member who dynamically decides the value will declare them like this, and the meaning of static will be lost in writing code. A better way is to convert $ var2 into an array and put the values of each CLASS in $ var [_ CLASS.

However, do not use static member inheritance unless necessary.

There is also a similar "pitfall ". When talking about private Members, we all know that private is private and does not inherit from the quilt class. However, sometimes I forget to write the code. It is not until I start to load the code that I remember that it was private, so that the subclass could not find this member, or that private was declared in the subclass, however, because the parent class function is called when a function is called, the private value of the parent class instead of the subclass is returned. In this case, it is impossible to rewrite the function as it is in the subclass. So be careful when using private.

When using the Rackspace SDK, we can see that some classes use private members. However, because they provide unnecessary permission to open files, the Code cannot run on our server. At this time, I would like to write a subclass to overwrite the initial values of this member. The result is that this is a private member, at last, we need to copy all the references to the subclass we write. Why don't we directly change the SDK to protected? Because the development kit may be upgraded next time? After modification, we can just remove the subclass. If you change the library code to a habit, you will not be so happy when you want to upgrade it. Therefore, you must be cautious when using private members. If you are developing sdks, you need to consider whether users need to inherit them? If you have to write private, can you ensure that the code can be used in various scenarios?

Unless you have a good reason, both static and private must be used with caution.