simple explanation PHP OOP vs Procedural?

Question 1

I would like to learn PHP and want to get an Idea about OOP and Procedural. I read some other blogs and tutorials about OOP vs Procedural but I still can't understand the approach.

OOP vs Procedural

Which I should learn?
What is the difference in code? What are the effects?
How can a PHP framework help in OOP aproach? (I would like to learn CodeIgniter)
Does procedural need a Framework?

I really want to know the code difference of the both, my understanding of OOP is you create a class like and it can be access. (I don't know if that is correct).

Question 2

Background: You asked for a "simple explanation" which suggests:

You want a no-nonsense overview without jargon
You want something that will help you learn from the beginning
You have discovered that no two people ever answer the question the same way, and it's confusing. That's the reason you are here asking for a simple explanation. Yes?

Short No-Jargon Answer:

Many introductory explanations jump quickly into "OOP real world" examples. Those can tend to confuse more than help, so feel free to ignore that for now.
You can think of source code simply as "chunks" of functionality, that just happen to be saved to individual files.
There are different ways of organizing those "chunks"; depending on things like conventions of the programming language, the background and training of the developer(s), or just plain old personal preference.
OOP and Procedural programming are simply two main, generally-recognized methodologies, for how to organize and arrange those "chunks" of code.

Long No-Jargon Answer:

Procedural vs OOP is just one aspect of a fundamental issue of computer programming: how to make your code easy to understand and a piece of cake to professionally maintain. You can actually write "Procedural" code that follows some of the principles of OOP, so the two are not necessarily opposites.

Your understanding will really grow once you learn other object-oriented programming languages, among which, PHP is a "new kid on the block".

Here is a quick overview of what you will learn as you build experience:

You can write PHP source code that does useful tasks
You can organize useful tasks into "chunks" of code
You can think of "chunks" of code independently of the individual files where they are saved
Sometimes those "chunks" of code will behave differently based on parameters you pass in
Chunks of code that accept parameters are called "Functions"
Functions can be "chunked" together, and there are different ways of doing this:
- For example: you could have just one big PHP file with all the functions you have ever written in your entire life, listed in alphabetical order by function name
- For example: you could have multiple PHP files with functions that are chunked together by subject matter [e.g., functions for doing basic string manipulation, functions for processing arrays, functions for file input/output, etc]
OOP is a special way of "chunking" Functions together into a "Class"
A Class is just another level of "chunking" code together so that you can treat it as a unified whole
A Class can be thought of as a "chunking" of methods and properties
- methods are simply functions that are logically related to one another in some meaningful way. The words "method" and "function" are basically two different terms for the same thing.
- properties are simply data values that are related to the class. These are values that are intentionally non-isolated to any individual function, because more than one of the functions in the class should have access to them.
  - For example: if your class has a bunch of methods for doing astronomy, properties of the class might be the values for certain famous numbers that all astronomy methods need to know about (like Pi, the speed of light, the distance between specific planets, etc.).
- This is where most OOP explanations get confusing because they branch off into "real world examples" which can quickly get off-topic. Often, "real world" is a euphemism for the ontological perspectives of a particular individual or group. That tends to be useful only once you already understand the concept well enough to teach it to someone else.
- To understand OOP without confusion, you can skip the "real world" examples for now, and just focus on the code. A Class is simply a way to store functions (aka methods) and properties (aka data) as PHP code in one or more related "chunks" where each individual "chunk" deals with a specific topic or piece of functionality. That's all you need to know in order to get started.
A Class is useful because it allows you to organize your code at a very high level in a way that makes it easy for you to understand, use, and maintain.
When someone has written a lot of functions, and organized them into a lot of Classes, and gotten those to work together in some cool way, they package the whole thing together and call it a "Framework".
A Framework is just the next-highest level of "chunking" (including coding style and conventions) that one or more people agree on because they like the way the code is organized and it suits their working style, preferences, values, plans for world domination, etc.

The answer to which one is better is "it depends." As with anything, there are a variety of different approaches and you should also keep in mind that code that uses objects is not necessarily object oriented but can still be written procedurally. In the same vein, code that does not use objects can still be modular.

I would choose to use the mysqli class every time, though. There is no significant difference in performance. You probably won't realize some of the advantages of using a DB class such as simplified polymorphism, so my only argument for using the class is that I prefer the syntax. However, rather than use mysqli directly I would probably recommend that you extend or compose it. You can only do this with the class.

class DB extends mysqli {
    public function __construct() {
        parent::__construct($_SERVER['DB_HOST'],
            $_SERVER['DB_USER'], $_SERVER['DB_PASS']);
    }
}

This is a very shallow example.

An example of the polymorphism I was talking about above would be something like this:

class User implements DAO {
    private $db;
    public function __construct(DB $db) {
        $this->db = $db;
    }
}

//Testing code is simplified compared to using it in production
class TestDB extends DB {}
new User(new TestDB);
new User(new DB);

By the way I categorically prefer PDO over mysqli

Question 4

You can test procedural code with PHPUnit. Unit tests are not tied to object-oriented programming. They test units of code. In OO, a unit of code is a method. In procedural PHP, I guess it's a whole script (file).

While OO code is easier to maintain and to test, that doesn't mean procedural PHP cannot be tested.

Per example, you have this script:

simple_add.php

$arg1 = $_GET['arg1'];
$arg2 = $_GET['arg2'];
$return = (int)$arg1 + (int)$arg2;
echo $return;

You could test it like this:

class testSimple_add extends PHPUnit_Framework_TestCase {

    private function _execute(array $params = array()) {
        $_GET = $params;
        ob_start();
        include 'simple_add.php';
        return ob_get_clean();
    }

    public function testSomething() {
        $args = array('arg1'=>30, 'arg2'=>12);
        $this->assertEquals(42, $this->_execute($args)); // passes

        $args = array('arg1'=>-30, 'arg2'=>40);
        $this->assertEquals(10, $this->_execute($args)); // passes

        $args = array('arg1'=>-30);
        $this->assertEquals(10, $this->_execute($args)); // fails
    }

}

For this example, I've declared an _execute method that accepts an array of GET parameters, capture the output and return it, instead of including and capturing over and over. I then compare the output using the regular assertions methods from PHPUnit.

Of course, the third assertion will fail (depends on error_reporting though), because the tested script will give an Undefined index error.

Of course, when testing, you should put error_reporting to E_ALL | E_STRICT.

Question 5

In general, as you've already stated, instance methods are the better practice. That isn't to say that static methods are downright evil, they simply have a different and unique purpose.

It is important to note that when dealing with instance methods you are working with an object whereas with static methods you are working with a class. When using static methods you will not have access to any of your non-static properties that would normally be available with an instance.

Take the following code as an example:

class Foo
{
    private $bar;
    private static $tavern;

    public function changeBar($value)
    {
        $this->bar = $value;
    }

    public function getBar()
    {
        return $this->bar;
    }

    public static function changeTavern($value)
    {
        self::$tavern = $value;
    }

    public static function getTavern()
    {
        return self::$tavern;
    }
}

Class Foo has a static property $tavern and a non-static property $bar.

If an instance of Foo is created then all properties and methods are available to that object.

If Foo is referenced statically then only the $tavern property, changeTavern() method and getTavern() method are available to the class.

Let's look at the following code:

$foo = new Foo();
$foo->changeBar('Tipsy Turvy');
echo $foo->getBar(); // prints Tipsy Turvy

Since $foo is an instance of Foo, it has access to the entire class. Calling changeBar() will modify the $bar property. To change the $bar property directly from a static method will trigger an error since $bar is available to the object and not the class.

// Calling this method would trigger an error
public static function changeBar($value)
{
    $this->bar = $value; // PHP will crash and burn if you try this.
}

If you want to access class properties from static methods those properties must also be declared static. This will work in the context of the class above. You'll also note that an instance of Foo has no problem reading static properties.

Foo::changeTavern('Stumble Inn');
echo Foo::getTavern(); // prints Stumble Inn
echo $foo->getTavern(); // also prints Stumble Inn

Another thing to remember about static code is that it doesn't behave like an instance. When the first instance of Foo was built both properties $bar and $tavern had no value. If you were to create another instance of Foo you would find that only one of those properties no longer contains a value. (I'm sure by now you can guess which one.)

$anotherFoo = new Foo();
echo $anotherFoo->getBar(); // prints nothing
echo $anotherFoo->getTavern(); // prints Stumble Inn
echo Foo::getTavern(); // prints Stumble Inn

So again, static code means you are working directly with a class - instances mean you are working with an object. It is important to note that any type of class you write that intends to have some kind of state to it should be used as an instance.

Static classes can be a little difficult to debug and test. Testing can be problematic because static properties don't change when you create a new instance. Debugging can also be difficult since the value of a static property is the same across all instances of an class. Make a change in one and you will make that change in all of them. Tracking down which instance made the change is a pain.

Speaking metaphorically, use static classes like sugar - sparingly and only when necessary.

Hope that helps shed some light on the topic.

Question 6

The difference between the two is subtle but significant.

In a procedural program, modules interact by reading and writing state that is stored in shared data structures.

In an object oriented program, modules in the form of objects interact by sending messages to other objects.

simple explanation PHP OOP vs Procedural?

Answers

See also

php,oop,procedural-programming,procedural