In the previous series of articles, I was concerned about re-organizing your function in one of the PHP Miscellaneous "refactoring-improving the design of existing code", but I still didn't think I made it clear, I also have a lot of points that I don't understand, and this is my first article in this regard. There are a lot of mistakes, so I will make frequent changes, if you have good comments, let us know the first and second mind map.
Introduction
Which of the first few articles I pay more attention? But I don't think I have made it clear. I also have a lot of questions that I don't understand, and this is my first article in this regard, which has many flaws, so I will make frequent changes. if you have any good suggestions, I 'd like to inform you.
Today we are talking about "interfaces", which are not "interfaces" but collectively referred to as "interfaces. Generally, we can call a function or url (usually used to provide data) for others' use as an interface. -- There may be other meanings. after all, I still belong to Cainiao. please correct me if you have any misunderstanding.
We know that "easy to understand and use interfaces" is the key to developing good object-oriented software. -- This article will introduce the refactoring method of "making interfaces more concise and easy to use.
Digress:
If you think that this article is too long and looks troublesome, we suggest you "read the text in the image and in bold".
Yesterday, "old" Boyou left me a message. I didn't think about it carefully before. I thought about it this time. The message content is:
I personally think that the value of a lot of things can be known only when we pay attention to it.
As for simplicity, the purpose of reconstruction is also simple and understandable.
As for persistence, I think we often need this kind of persistence in technology. even if you think you are wrong later, we will continue to reap some benefits. We can only learn the value of this kind of break-in experience many times (this kind of break-in is both correct and wrong) and get what we need.
As for the benefits, "Old" is not about the company's interests. well, it is true that many times we need to catch up with the progress in the coding process, and we also have some errors in restructuring, so my advice is that at the beginning of development, you should constantly work in the design and reconstruction, and do not feel that it is a waste of time. in many cases, a good structure can accelerate your development.
Terminology
Rename Method
Condition: if the function name does not reveal the function's purpose, modify the function name.
Motivation:
One of the programming styles I strongly advocate is to break down complicated processing processes into small functions. However, if the name of a small function is poor, it will make you struggle to understand their respective uses.
A good way to name a function: consider what kind of annotation should be written to the function ---> try to change the annotation to the function name.
It is not easy to get a good name and requires experience. -- To become a real programmer, the level of naming is crucial.
If you see that a function name cannot express its purpose, you should modify it immediately.
Example:
Add Parameter
Condition: if a function needs to obtain more information from the caller, add a parameter to the function to bring the required information into the function.
Motivation:
1. Add Parameter is a common refactoring method.
2. the modified function requires information that is not available in the past. Therefore, you need to add a parameter to the function.
3. except Add Parameter, other options are better than "Add Parameter" if possible, because other options may not increase the length of the Parameter column. -- Too long parameter columns will make the programmer unable to remember so many parameters.
Remove Parameter
Condition: The function body does not need a parameter, so this parameter is removed.
Motivation:
1. parameters indicate function information. different parameters indicate different meanings. Function call requires you to worry about what to upload for each parameter. -- If you do not remove the parameter, you will be charged for each call.
2. if you find that there are many callers, you can set the parameter to be removed to a default value (such as null) to avoid the caller's worries ), in this way, the caller only transmits parameters without default values.
Separate Query from Modifier
Status:If a function returns both the object state value and modifies the object state (state ),
Create two different functions, one for query and the other for modification..
Example:
Parameterize Method
Status:If a number of functions do similar work but contain different values in the function ontology
Create a single function to express those different values with parameters.
Motivation:1. generally, several similar functions are created because a few values are different. 2. the separated function is replaced with a unified function. parameters are used to handle those changes to simplify the problem. 3. remove duplicate codes to improve flexibility. -- You can use this parameter to handle other changes.
Example:
Replace Parameter with Explicit Methods
Status:You have a function that takes a different response depending on the parameter value.
Creates an independent function for each value of this parameter.. Motivation:1. if a parameter has discrete values, and these parameter values are checked in the function in a conditional manner, and different responses are made based on different parameter values, this refactoring should be used. 2. benefits: "Code check during compilation" and "interface clearer" (if the parameter value is used to determine the function behavior, the function user not only needs to observe the function, it also determines whether the parameter is "legal ". -- Valid parameters are rarely mentioned in the document and must be determined by context.) 3. do not consider the advantages of the "compile-time check". to obtain a clear interface, we also deserve this.
Example:
Preserve Whole Object
Status:If you extract several values from an object and use them as parameters in a callback function call
Change to use (pass) the entire object. Motivation: 1. more stable parameter columns; 2. improved code readability; -- too long parameter columns are difficult to use, because callers and callers must remember the purpose of these parameters.
Example:
Replace Parameter with Methods
Status:If the object calls a function and passes the result as a parameter to another function (the function that accepts the parameter also has the ability to call the previous function), then
Remove this parameter from the parameter receiver and directly call the previous function..
Motivation:1. if the function obtains the parameter value through other means, it should not obtain the value through the parameter. 2. too long parameter columns increase the reader's understanding difficulty. Therefore, we should try our best to shorten the length of parameter columns. 3. method: check whether "parameter receiver" can obtain the parameter carrying value through "same calculation as the caller. 4. if the function caller computes parameters through another function in the object and "does not reference other parameters of the caller" during the calculation ", you can transfer this calculation process to the called End to remove this parameter.
Example:
Introduce Parameter Object
Status:Some parameters always appear at the same time.
Replace these parameters with an object.
Motivation:
1. a set of parameters may be used by several functions at the same time. these functions may belong to the same class or different classes. -- Such a set of parameters is the so-called Data Clump ). 2. we can use an object to wrap all the Data and replace Data Clump with an object. -- Goal: even if we only want to organize the data together, it is worthwhile to do so. 3. the value of this reconstruction is "shortening the length of the parameter column ". In addition, the accessors defined by the new object can make the code more consistent. -- This further reduces the difficulty of understanding and modifying the code. 4. this reconstruction can also bring you more benefits. -- When you organize these parameters together, you can quickly find the behavior of "new class can be transplanted. -- Reduce repeated code.
Example:
Remove Setting Method
Status:A value field in your class should be set at the beginning of the object, and then it will not change.
Remove all setter functions of the value range ).
Motivation:1. if you provide a setter function for a value range, this implies that the value range can be changed. 2. if you do not want the value to change after the object is created, do not provide the setting function for it. -- In this way, your intention will be clearer and you can exclude the possibility of modifying its value.
Example:
Hide Method
Status:If a function has never been used by other classes
Set this function to private.
Motivation:
1. refactoring often prompts you to modify "function visibility". -- Always check for hidden functions. 2. check whether it is possible to reduce the visibility of a function (making it private ). --> When you remove a call to a function from another class, you should check the call. --> Perform the preceding checks on the setter function. Replace Constructor with Factory Method
Status:If you want to create an object instead of simply performing component actions on it
Replace _ construct (constructor) with the factory method.
Motivation:
Replace type code with the factory method in the subclass process. -- You may often need type code to create the corresponding object.
Example:
Next:
Replace Error Code with Exception
Status:If a function returns a specific code (special code) to indicate an error
Exception).
Motivation:Clearly separate "Common Program" from "error handling", which makes the program easier to "understand".
Example:
Conclusion shares with you all my gains. if you have any small gains, I am also very happy. If there are any errors in the article, please give me some advice. I don't know if I have found the wrong place. some bloggers leave a message saying "C # is popular in blog Gardens". do you think PHP programmers are the main ones? Few people leave messages to me, and few people point out the errors in my article (are there really no errors in my article ?), Yesterday, "@ four-eyed masked man" gave me some comments. I learned a lot from my conversations with him, thanked him for his criticism, and hoped to communicate with you more.
