What problems I will face if I do not use OO-PHP? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 12 years ago.

I faced one; I've set sam开发者_运维知识库e variables names and that made me crazy, I had to check all the variable names and I had to keep them in mind. Now I realize that it wouldn't be issue with OO since hey would be hidden (encapsulated?).

What other problems I'll face if I do not use OO?

---

The main point of OO is packaging together what belongs together. See this simple example of storing and outputting customer data:

$customers = array(
    array('id' => 1, 'firstname' => 'John', 'lastname' => 'Doe', 'address' => 'Foobar Lane', …),
    array('id' => 2, 'firstname' => 'Jane', 'lastname' => 'Dough', 'address' => 'Foobar Road', …)
);

function output_customer_name($customer) {
    return $customer['firstname'] . ' ' . $customer['lastname'];
}

function output_customer_address($customer) {
    return $customer['address'] . ', ' . $customer['state'] . ', ' . $customer['country'];
}

foreach ($customers as $customer) {
    echo output_customer_name($customer);
    echo output_customer_address($customer);
}

You need to declare a different function for each type of data you want to output about a customer (this is only a simple example, output may be much more complicated). Imagine you not only have customers, but also products. Now you also have output_product_name and output_product_description functions. Your data structure (the $customer array) is not well defined though. You may change it at any time, which would break all your output functions if you forget to update them. You may also accidentally input a $product into a output_customer_name function, which would break everything.

Enter OOP:

class Customer {
    protected $firstname;
    protected $lastname;
    protected $address;
    …

    public function __construct($firstname, $lastname, $address, …) {
        $this->firstname = $firstname;
        $this->lastname = $lastname;
        $this->address = $address;
        …
    }

    public function name() {
        return $this->firstname . ' ' . $this->lastname;
    }

    public function address() {
        return $this->address . ', ' . $this->state . ', ' . $this->country;
    }
}

$customers[] = new Customer('John', 'Doe', 'Foobar Lane', …);
$customers[] = new Customer('Jane', 'Dough', 'Foobar Road', …);

foreach ($customers as $customer) {
    echo $customer->name();
    echo $customer->address();
}

Your data structures and the functions that are supposed to work on them are bundled into one object. No chance you're going to feed a $product into a function that was supposed to output customers. Your function names are also a lot shorter and your namespace isn't cluttered with a gazillion functions. You're not running the risk of typo'ing array keys on every assignment of data into data structures ('John' to $firstname). The complexity of dealing with customers has all been packaged up into the object. Contrast with the procedural way, where data structures, functions and dealing with both was all equally complex and error prone. In OOP, your objects are complex, but the code that deals with the objects is terrifically simple with almost no chance of making any sort of mistake.

And this is only a very simple example. The more complex your projects get, the more benefit you get from properly structured objects as opposed to loosely structured functions and variables. Complexity is not evenly spread throughout your whole codebase, it is bundled up in objects. Since the code "outside" the objects has been simplified, these objects can themselves become part of even more complex code, without the complexity of your whole codebase increasing exponentially with each new entity (products, customers) you introduce. It's all about making it harder for you to shoot yourself in the foot and making your code more readable and better structured. Encapsulation, abstraction etc are the natural side-effects that follow from bundling related things together. They're what enables you to write simpler code, which in turn enables you to write more complex code without your head exploding.

It's perfectly possible to write complex applications in procedural code. In reality though, stuff changes. Even if you're a genius and can plan the entire structure of your application beforehand, requirements change. You'll need to extend, change and maintain your codebase over time. This is a lot easier with properly structured, abstracted, encapsulated, type-checked code than with a Rube Goldberg machine of individual variables and functions.

---

It depends on the kind of system (at least I would say). If you are handling huge amounts of information or making larger systems that are supposed to integrate with future PHP projects too, object oriented programming may be the best approach.

It's hard to tell given no explanation of what you are going to make. I also believe that the question is hard to give a concrete answer for, so what I've given here is rather an opinion than a fact.