In this tutorial, we’ll gonna introduce some “tools” that would allow us to check an object’s parents, its class, what it has inherited and what interfaces are implemented upon it. I won’t go through all of the functions because they are a lot and besides, the majority of them are really self-explanatory and the documentation about them is good enough even for beginners.
I’ll be using the following files in this tutorial (stating it here to avoid confusion): index.php, SuperMan.php, Human.php.
Object Types Validation
Let’s include the SuperMan.php file in our index.php
<?php
include 'SuperMan.php';
In the SuperMan.php file I have included Human.php and made a class with a few methods for data supply. Here is the code so that you may gain better understanding and of course to be able to carry on with the tutorial.
<?php
include 'Human.php';
class SuperMan extends Human{
public function __construct() {
parent::__construct();
echo 'Superman construction<br />';
}
public function goToEat(){
echo 'I refuse';
}
public function showFace(){
echo 'Show<br />';
}
public function drive(){
$this->driveCar();
}
}
?>
So index.php inherits SuperMan and SuperMan by itself inherits Human.php. Human.php has an included Animal.php class and so on. The idea is just to have multiple inherits of classes and objects so that we may show how it works. Now here is the class Human (it has nothing specific within it - just a few more methods).
<?php
include 'Animal.php';
class Human extends Animal {
public function playWow(){
echo 'Wow<br />';
}
protected function driveCar(){
echo 'Car<br />';
}
}
?>
Now let’s make a new instance of SuperMan in our index.php and we want to check whether that object that is appended to the variable $human is an instance of the class SuperMan. So let’s do this with the well-known function var_dump() and use the keyword instanceof. First we define the variable that is handling the instance then we use the keyword instanceof and the name of the class.
<?php
include 'SuperMan.php';
$human = new SuperMan();
var_dump(($human instanceof SuperMan));
?>
Within the second pair of brackets, we’ll receive the output in boolean type. Since the object $human is an instance of SuperMan so therefore we get returned:
bool(true)
What if we want to check whether the object is from class Animal.
<?php
..
var_dump(($human instanceof Animal));
..
?>
We will get the same result because Animal is the main class. Basically, speaking SuperMan inherits Human, Human inherits Animal. So SuperMan is part of the class Animal, so instance of will return us a boolean true for any of the classes we currently dispose with because that is the so-called tree structure. This is the way we can validate whether an outside object corresponds to the requirements we have defined. Later on you’ll see that in object-oriented programming a lot of objects are being gathered in a file and let’s say we have an incoming object and we would then want to validate whether the object is from the correct type and whether it implements the appropriate interfaces.
Let’s run the following:
<?php
include 'SuperMan.php';
$human = new SuperMan();
$human2 = new Animal();
var_dump(($human instanceof $human2));
?>
The examples I’ve given above are just comparing and checking class names but we can also use variables like in this example to validate the object and instance. So practically whether one object is an instance of another.
Now there are several other functions that are used in more specific cases. Some of them are:
class_alias();
- Generates an alias of a desired class
class_exists();
- Checks whether the class has been defined
get_class();
- Outputs the name of a class that is part of an object
is_a();
- Checks whether an object is of a class and does not include interface implementations like instanceof
method_exists();
- Checks whether a class method is available
property_exists();
- Checks whether an object or a class has a defined property
trait_exists();
- Checks whether a trait is existent
Documenting of Methods & Properties
Basically, documenting is just writing comments but in a more specific way. Most people would ignore that totally, but when it comes to massive projects, all those tiny little things I use to talk about in my tutorials and anywhere at all will come in handy for sure. As well as that, documentation is useful for other programmers that would interfere in our code or just for our own ease.
<?php
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
/**
* Description of Doc
*
* [@author](/profile/author) Keeper
*/
?>
This template is generated by an IDE (Netbeans). Those types of comments are specific for object-oriented programming and luckily they are almost the same in all programming languages. It’s accepted that when we have a class, the first few lines should be describing it most briefly, from which object it is, whether it is part of an administration module and so on. We don’t need to be too describing, we just need to handle the idea of what the project is about. Whether it would be a GPL, Apache or open source license and so on.
Now when we have this:
<?php
/**
*/
?>
Here in free-text we describe what the class is going to do (convert text to PDF, word unscrambler, modules etc.) and there are also some specific tags like “@” the at symbol which have some keywords embedded about themselves. For example:
<?php
/**
* [@author](/profile/author) Keeper
*/
?>
In Netbeans there is a whole documentation about them in the environment itself. They are all more than self-explanatory and their usage is totally unnecessary but in order to keep things ‘tidy’ and help ourselves when we are releasing the code as a product, we’d require those comments and documentations at the beginning of our file, whether it would be our license, copyright, disclaimer, about section or whatever.
Also, as you might guess, those comment lines (no matter that they are count as ‘special’ - documentation) do not alter the way our code is being processed and then executed. They are after all just simple comments. But bear in mind that in Java annotations, things are different. They alter the way of work and are also written differently.
Now let’s make a simple and pretty much the most basic method we could think of just to see it in practical use:
<?php
public function test($a,$b){
return true;
}
?>
This is a senseless method which has no return value or any logical output. The idea is just to see how the comments are being generated. Now Netbeans automatically generates the documentation for the method upon typing /** and hitting enter.
/**
* This is a test dummy method
* [@param](/profile/param) type $a
* [@param](/profile/param) type $b
* [@return](/profile/return) type
*/
In the first line we can write our description and then we have those predefined tags with the parameters we have for you method and the return type. Let’s modify them a bit and see what we’ll get later on. Suppose, I want to change the param tags into a more informative ones.
/**
* This is a test dummy method
* [@param](/profile/param) string $a name of the user
* [@param](/profile/param) int $b age of the user
* [@return](/profile/return) bool
*/
Most environments use this documentation in run-time. Now let’s include this documentation of the class in our index.php and beforehand add another method to our class just so that we may view the auto-completion process.
<?php
include 'Doc';
$d = new Doc();
$d -> test();
?>
We’ll get the documentation we had written some time ago for the method that we are referring to. The reason why I made a second method with no return value is that we could use it as an auto-completion example but we are good without it as well. So here’s what our documentation is being represented like in Netbeans.
Now let’s document a single property. There is again, literally, no difference. Though it is rarely used to document properties especially, I just want to put an example to make it clear that there is practically no difference and nothing confusing.
<?php
/**
*
* @var String
*/
public $name = 'Keeper';
?>
Conclusion
This is by far the easiest tutorial over my object-oriented series for PHP. Sixth part of the series, been a while since I posted the last one but I lacked the time to continue my series. Practically, you could simply grasp the logic from a cast of a glance but I needed to show you all the things there are about it. As I said before those ‘techniques’ are used for detailed and in-depth projects where there are a lot of people working on the same code and they need to document most of the things. Thanks for reading!
