Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
Visibility scope is not the only object-oriented way to restrict access. PHP5 also introduced the concept of abstract classes and methods. If a class is defined as abstract, it cannot be instantiated. If you define a method as abstract, then any class that extends that abstract class containing the method must also declare a method with the same name and arguments. Further, if a class has an abstract method, then the class itself must be abstract.
This solves the problem of the generic address class, and provides a mechanism to specify the behavior of any child classes. Open the address class, scroll to the top, and add the word "abstract" at the beginning of the class declaration. Save the address, then switch to your browser, and refresh the demo. At the bottom, the attempted instantiation of the generic address class has been disallowed, and caused a fatal error. This is a good thing, as it forces the developer to be specific. Edit the demo, and re-factor the second address instance to be a business address, including the variable name. AddressBusiness. address_business for the variable name as well. And then, add a var_ export at the end, so we can inspect the contents. Save the demo, go back to the browser, and refresh.
The business address is now displayed correctly. However, there is a data inconsistency; it's the correct class (AddressBusiness), but the _address_type_id is not set. Missing property values is a common development problem. When working with multiple similar objects, there can be a lot of easily forgotten details to keep track of. The solution is to initialize objects automatically, so you don't have to remember to do it, but what's the best way to initialize them? Your first reaction may be to make the construct magic method abstract. This would technically work, but you'd end up with a lot of copied and pasted code, as everything in construct would have to be duplicated.
This can easily lead to a fragile system, where re-factoring or adding new functionality becomes cumbersome. It's not a best practice, and not very object-oriented. Instead, I'm going to construct the object in the parent, then call an abstract initializer. This way, common behavior in the parent's construct method always executes upon instantiation. Then, custom behavior can be put in each child's initialization method. Neat! With these relationships, visibility is also a factor, and abstract method visibility can be a bit tricky.
Methods that implement an abstract method will also need to have the same scope, or something a little bit less restrictive. If an abstract method is declared as public, I won't be able to change it to private. However, the opposite is true. I can make an abstract private method public. It's a one-way change. You can relax the scope restriction, but not make it stricter. This prevents a situation when you're expecting to be able to do something, but for some strange reason, you are prevented by scope.
To practically apply this to the addresses, I'm going to require that extending classes set the address type id upon creation. Let's open the Address class. After the magic method toString, define a new abstract protected method called init, abstract protected function _init(). Force extending classes to implement init method, then add a call to the initialization method at the beginning of the constructor. $this->init. Save the address class, then go to your browser, and refresh.
You will see an immediate error. The AddressResidence class contains an abstract method that needs to be defined. So, open the AddressResidence class, and declare the private function initialized. protected function _init(). Set the address type id to the constant from the address class, using your validating method: $this-> setAddressTypeIDAddress::ADDRESS_TYPE_RESIDENCE. Add some documentation, and copy the contents of this method, and paste it into the business address. ADDRESS_TYPE_ BUSINESS. And, again for the Park. Save, then return to your browser, and refresh.
You'll see that the _address_type_id for the business is now set correctly. However, a redundancy has now been introduced with the potential for corruption. You can still set the _address_type_ id manually, and if you look at the demo, AddressResidence is doing just that. You can just remove the _address_type_id, but that treats the symptom, not the problem. Return to the address class, and navigate to the magic set method. Remove the special case for _address_ type_id. Save, then refresh the demo.
You will see a notice for undefined or unallowed property. Data corruption is now prevented. Edit the demo, and remove the now- broken attempt to set the _address_type_id. Then save, and refresh. The notice is now gone, and execution is error-free. In the next segment, I'm going to demonstrate how to implement a common interface across all these child address classes without having to know what kind of an address type it is.
Get unlimited access to all courses for just $25/month.Become a member
82 Video lessons · 98181 Viewers
61 Video lessons · 85482 Viewers
71 Video lessons · 69439 Viewers
56 Video lessons · 101790 Viewers
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Your file was successfully uploaded.