Why use PHP OOP over basic functions and when?

In a lot of scenarios, procedural programming is just fine. Using OO for the sake of using it is useless, especially if you're just going to end up with POD objects (plain-old-data).

The power of OO comes mainly from inheritance and polymorphism. If you use classes, but never use either of those two concepts, you probably don't need to be using a class in the first place.

One of the nicest places IMO that OO shines in, is allowing you to get rid of switch-on-type code. Consider:

function drive($the_car){

    switch($the_car){

      case 'ferrari':
          $all_cars->run_ferrari_code();
          break;

      case 'mazerati':
          $all_cars->run_mazerati_code();
          break;

      case 'bentley':
          $all_cars->run_bentley_code();
          break;
    }
}

with its OO alternative:

function drive($the_car){

    $the_car->drive();
}

Polymorphism will allow the proper type of "driving" to happen, based on runtime information.

Notes on polymorphism:

The second example here has some premisses: That is that all car classes will either extend an abstract class or implement an interface.

Both allow you to force extending or implementing classes to define a specific function, such as drive(). This is very powerful as it allows you to drive() all cars without having to know which one you're driving; that is because they're extending an abstract class containing the drive() method or implementing an interface forcing the drive() method to be defined.

So as long as you make sure that all your specific cars either extend the

Using an object-oriented programming approach rather than a procedural programming approach in a program doesn't really depend on the language (be it PHP or not), but on the type of problem you are trying to solve.

(I'm just going to use pseudocode in my examples as I am not too familiar with PHP.)

For example, if you have a program where you are just performing a bunch of functions in order, then procedural is going to be fine. For example, if it's a simple string manipulation program, a procedural approach would suffice:

perform_truncation(my_string, 10)
to_upper(my_string)
perform_magic(my_string, hat, rabbit)

However, if you're going to deal with many different items (such as files, or any other representation of, well, objects) then an object-oriented approach would be better.

For example, if you had a bunch of Cars and wanted them to drive, then in procedural, you may do something along the line of:

drive_car(first_car)
drive_car(second_car)

Where as, in OOP, the Car can drive itself:

RedCar myRedCar();
BlueCar myBlueCar();

myRedCar.drive();
myBlueCar.drive();

And, as each car is a different class, their behavior can be defined differently. Furthermore, they may be both subclasses or Car they may have common functionality.

It really comes down to the type of problem which makes either procedural approach better than object-orientated and vice versa.

Aside from the issue of procedural or object-oriented, it may be a kind of "code smell" to have one source file with many functions. This can also be said about classes which contain many functionalities which may be better performed as separate functions in separate classes.

The issue here may be of code organization rather than deciding to pick procedural or object-oriented programming. Organizing functions int