Develop 7 good object-oriented habits in PHP

In the early days of PHP programming, PHP code was inherently limited to process-oriented. The process code is characterized by the use of procedures to build application blocks. Procedures provide some degree of reuse by allowing calls between procedures.

However, without object-oriented language constructs, 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 mixed paradigm (a process language that contains pseudo OO design). Using OO constructs in PHP code-such as the ability to define and use classes, the ability to build relationships between using inherited classes, and the ability to define interfaces-makes it easier to build code that conforms to excellent OO practices.

Although not much modular pure process design works well, the benefits of OO design are maintained. Because most of the lifecycle of a typical application is spent on maintenance, code maintenance is an important part of the application lifecycle. and code maintenance is easy to forget during the development process. If there is competition in application development and deployment, long-term maintainability may be relegated to a relatively minor position.

Modularity-One of the key features of excellent OO design-can help with this maintenance. Modularity will help encapsulate changes so that applications can be extended and modified more easily over time.

Overall, although there are more than 7 habits of building OO software, following the 7 habits here can make code conform to basic OO design standards. They will provide you with a firmer foundation on which to build more OO habits and build software that can be easily maintained and extended. These habits are designed to address several key features of modularity. For more information on the advantages of language-independent OO design, see resources.

7 Excellent PHP OO habits include:

Remain humble.

Be a good neighbour.

Avoid seeing Medusa.

Take advantage of the weakest link.

You are an eraser, I am a glue.

Restrict propagation.

Consider usage patterns.

Stay humble.

Staying humble means avoiding exposing yourself in class implementations and function implementations. Hiding your information is a basic habit. If you can't get into the habit of hiding the details, it's hard to develop any other habits. Information hiding is also known as encapsulation.

There are a number of reasons why it is a bad habit to expose public fields directly, and the most important reason is that you don't have the choice to implement the changes. Isolate changes using OO concepts, while encapsulation plays an integral role in ensuring that changes are not inherently viral (viral) changes. A viral change is a small change at first-such as changing an array that holds three elements to an array that contains only two elements. Suddenly, you find that you need to change more and more code to accommodate changes that are supposed to be trivial.

An easy way to start hiding information is to keep the fields private and expose them using public access methods, just like windows in your home. Instead of opening the entire wall to the outside, open only one or two windows (I'll introduce more information about the access method in "Good habits: using Public access Methods").

In addition to allowing your implementation to be hidden after a change, using a public access method rather than directly exposing the field will allow you to build on the base implementation, by overriding the implementation of the access method to perform a slightly different behavior from the parent method. It also allows you to build an abstract implementation that delegates the actual implementation to the class that overrides the basic implementation.