7 good habits of PHP object-oriented programming (1) _ PHP Tutorial

7 good habits of PHP object-oriented programming (1 ). In the early days of PHP programming, PHP code was essentially process-oriented. The feature of process code is to use process to build application blocks. By allowing calls between processes, a process is provided in the early stages of PHP programming. PHP code is essentially limited to process-oriented. The feature of process code is to use process to build application blocks. A process provides a certain degree of reuse by allowing calls between processes.

However, without object-oriented language structures, programmers can still introduce OO features into PHP code. This is a bit difficult and makes the code difficult to read, because it is a hybrid example (containing a pseudo OO design process language ). Use OO construction in PHP code-for example, defining and using classes, building relationships between inherited classes, and defining interfaces-you can easily build code that conforms to excellent OO practices.

Although there are not many modular pure process designs that run well, the advantages of OO design are in maintenance. Because most of the lifecycle of a typical application is maintained, code maintenance is an important part of the application lifecycle. In addition, code maintenance is easy to forget during the development process. If there is competition in application development and deployment, long-term maintainability may be placed in a secondary position.

Modularization-one of the main features of an excellent OO design-can help with such maintenance. Modularization will help encapsulate changes so that applications can be expanded and modified more easily over time.

In general, although there are more than seven habits of building OO software, following these seven habits can make the code conform to the basic OO design standards. They will provide you with a stronger foundation on which to build more OO habits and build software that can be easily maintained and expanded. These habits target several main features of modularity. For more information about language-independent OO design advantages, see references.

Seven excellent php oo habits include:

◆ Be humble.
◆ Be a good neighbor.
◆ Avoid seeing Medusa.
◆ Use the weakest link.
◆ You are an eraser; I am a glue.
◆ Restricted propagation.
◆ Use mode.

Be humble

To be modest, avoid exposing yourself in class implementation and function implementation. Hiding your information is a basic habit. If you cannot develop the habit of hiding implementation details, it will be difficult to develop any other habits. Information hiding is also called encapsulation.

Public fields are a bad habit for many reasons. The most important reason is that you do not have the proper choice in implementing changes. Use the OO concept to isolate changes, while encapsulation plays an indispensable role in ensuring that changes are essentially not viral (viral) changes. A viral change is a small change at the beginning-for example, an array that saves three elements is changed to an array that contains only two elements. Suddenly, you find that you need to change more and more code to adapt to the negligible changes.

One simple way to start hiding information is to keep the fields private and expose them using public access methods, just like the windows in your home. The whole wall is not open to the outside, but only one or two windows are opened (I will introduce more information about the access method in "good habits: using public access methods ).

In addition to allowing your implementations to be hidden after the changes, using public access methods rather than directly exposing fields will allow you to build on the basis of the basic implementation, the method overwrites the implementation of the access method to execute behavior slightly different from that of the parent method. It also allows you to construct an abstract implementation so that the actual implementation is delegated to override the basic implementation class.

Bad habit: publish public fields

In the example of bad code in listing 1, the field of the Person object is directly exposed as a public field rather than an access method. Although this behavior is very attractive, especially for lightweight data objects, it will limit you.

◆ List 1. bad habits of making public fields public

＜?phpclass Person{ public $prefix; public $givenName; public $familyName; public $suffix;}$person = new Person();$person-＞prefix = "Mr.";$person-＞givenName = "John";echo ($person-＞prefix);echo($person-＞givenName);?＞

If the object has any changes, all code that uses the object also needs to be changed. For example, if someone's teaching name, last name, and other names are encapsulated in the PersonName object, you need to modify all the code to adapt to the change.

Good habit: use public access

By using good OO habits (see listing 2), the same object now has private fields rather than public fields, the get and set public methods called access methods are used to cautiously disclose private fields to the outside world. These access methods now provide a public method for getting information from the PHP class, so that when the implementation changes, the need to change all the code using the class is likely to become smaller.

◆ List 2. good habits of using public access methods

＜?phpclass Person{ private $prefix;private $givenName; private $familyName; private $suffix;public function setPrefix($prefix) {$this-＞prefix = $prefix; }public function getPrefix() { return $this-＞prefix;} public function setGivenName($gn){$this-＞givenName = $gn;} public function getGivenName() {return $this-＞givenName;} public function setFamilyName($fn){$this-＞familyName = $fn;} public function getFamilyName() {return $this-＞familyName;} public function setSuffix($suffix){$this-＞suffix = $suffix;} public function getSuffix() { return $suffix;} }$person = new Person(); $person-＞setPrefix("Mr.");$person-＞setGivenName("John");echo ($person-＞getPrefix());echo($person-＞getGivenName());?＞

At first glance, this code may do a lot of work, and in fact it may be more of the work at the front end. However, it is usually very cost-effective to use good OO habits in the long run, because it will greatly consolidate future changes.

In the code version shown in listing 3, I have changed the internal implementation to use the joined array of the name component. Ideally, I want to handle errors and check whether the elements exist more carefully, however, the purpose of this example is to show the extent to which the code using my class does not need to be changed-the code is not aware of the class change. Remember that the reason for adopting OO habits is to carefully encapsulate changes so that the code is more scalable and easier to maintain.

1

Pipeline code is essentially process-oriented. The feature of process code is to use process to build application blocks. A process provides some...