Why use PHP OOP over basic functions and when?

Question

There are several posts on this subject, but I did not understand when to use object-oriented coding and when to use program functions in include. Someone also mentioned to me that OOP is very hard to work and does more workload. Is it correct?

Say I have a large file with 50 functions. Why do I want to name them in class? And not by function_name ()? Should I switch and create an object that contains all my functions? What will be the advantage or the specific difference? What benefits does it bring for OOP code in PHP? Modularity?

Answer 1

In many scenarios, procedural programming is just fine. Using OO to use it is useless, especially if you just end up with POD (plain old data).

The strength of OO is mainly related to inheritance and polymorphism. If you use classes, but never use either of these two concepts, you probably don't need to use the class in the first place.

One of the most enjoyable places in which the IMO, in which the OO shines, allows you to get rid of code like inclusion. 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 for the proper type of “driving” based on runtime information.

---

Notes on polymorphism:

The second example here has some premises: all car classes will either extend the abstract class or implement the interface .

Both allow you to force classes to expand or implement to define a specific function, such as drive() . This is very powerful because it allows you to drive() all cars without knowing which one you drive; this is because they extend an abstract class that contains the drive() method or implements an interface that forces the drive() method to be defined.

So, until you make sure that all your specific machines extend the abstract car class or implement an interface such as canBeDriven (both of which must declare the drive() method), you can simply call drive() on an object that, as you know, is a car (but not what type of car), without fear that it is not detected, because PHP will generate fatal errors until you define these methods in your specific car classes.

Answer 2

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

(I will just use pseudo-code in my examples, as I am not very familiar with PHP.)

For example, if you have a program in which you simply perform a bunch of functions in order, then the procedure will be fine. For example, if this is a simple string-processing program, a procedural approach is enough:

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

However, if you are going to deal with many different elements (for example, files or any other representation of the objects of the desired object), then an object-oriented approach would be better.

For example, if you have a bunch of Car and you want them to be drive , then in the procedure you can do something line by line:

 drive_car(first_car) drive_car(second_car) 

Where, in OOP, Car can control itself:

 RedCar myRedCar(); BlueCar myBlueCar(); myRedCar.drive(); myBlueCar.drive(); 

And, since each car is a different class, their behavior can be defined in different ways. In addition, they can be either subclasses or Car , they can have common functionality.

It really comes down to the type of problem that makes either a procedural approach better than an object-oriented approach, and vice versa.

Besides the problem of procedural or object-oriented, it can be a kind of “code smell” to have one source file with many functions. This can also be said of classes that contain a lot of functionality that can better be performed as separate functions in separate classes.

The problem here may be with the organization of the code, and not with the choice of procedural or object-oriented programming. Perhaps there are functions for organizing individual source files, except for abandoning the procedural approach to writing a program.

After all, there are many programs written in procedural programming that are well written and easy to maintain.

Answer 3

I will try to keep my answer as a supplement, because the answers of Majd Tabi and Coobard are really good.

I was mainly a procedural programmer for several years and did not struggle with OOP programming, but really did not see much significance ... this until I started working on the team and built more important and complex projects.

OOP really shines, in my opinion, when you need to write lean, easy-to-repair code for more complex applications. And remember that you are not in any situation, but there are some where the procedure simply will not work so well.

Most of my examples of excellent OOP implementations are projects in which I had several things that were related to each other, but all a little different. Sites with many forms, many users, many products, etc.

They all have similar behavior names, such as print (), update (), etc., but by encapsulating them as objects and changing the implementation of methods in classes, I can make my code at run time very simple and clean in all sites . In addition, this one was the key, despite the fact that I had different behavior, I could work with different objects using the same method calls throughout the application . This allows the second developer to work on a real implementation while I work on deeper code.

I don’t know if this helps anyone but to be a person who was in your situation not so long ago, I love OOP.

Answer 4

Suppose I have a large file with 50 functions, why do I want to call them in a class? not function_name (). Should I switch and create an object that contains all my functions?

Moving to OOP should not be seen as a simple “switch” in the way you described above.

OOP requires a completely different way of thinking about programming, which involves reworking your brain. Since brain rewinding does not happen overnight, many people are reluctant to subject themselves to the required rewinding process. Unfortunately, reworking will require investment in time and effort: research, study guides, trial version, and error.

This is really about taking a step back and learning about the concepts of OOP, but the payback will be worth it as someone who went through this process in the early days of www.

After you receive it and follow the recommendations of the OOP in your daily life, you will tell others how your programming life has changed for the better.

Once you really understand OOP, you will answer your question.

Answer 5

If you have 50 functions instead of 50 static methods in the Utility class, you "pollute" the global namespace.

Using a class with 50 static methods, method names are local to your class.

Answer 6

I can’t say which one is better. but in my experience you can improve code management with OOP. you know what code is where, what functionality is defined in which file, etc. about the lack of runtime for OOP I read somewhere (and I think it’s true) that if you write bad code in classical functions and the same bad code in OOP, then the functional version works better. therefore, if your code is not written poorly, there is no evidence that OOP slows down your application. also remember that these “slow” and “overhead” things are measured in milliseconds. therefore, if your application does not serve many users (for example, more than 100 users per minute), you may not feel any difference.

Answer 7

OOP allows you to create structured containers of code called classes, which can be parents / children of each other. This can help in building the application because it is easier to maintain and, if done, can properly reduce code redundancy. OOP adds a bit of overhead, but it's not very noticeable and is outweighed by the unsupported procedural code. If you are writing a large application, open OO, especially if it will work for many people.

For example, let's say you are developing a simple website. You can create a Page object. The page object is responsible for navigating to the database and retrieving various page parameters, such as metadata, title tags, or even the number of defined “components” on the page and their type (for example, a calendar control, widget, etc.).

Then you can create another class, such as Index, which extends the page. The index will be the index or the main page. If you have a product catalog, you might have a catalog class extension page. Since both your catalog section and your home page should receive data from the database of page metadata and the basic design of the page, you will need 1 object that already helps you. In both of these situations, the page does all the work and gets the page data from the database, loads it into variables, which are then available both in your index class and in your catalog class. You do not need to write code to enter the database and get it again on every page that you write.

Now there are other ways to do this procedurally, for example using include. However, you will find that you make fewer mistakes and mistakes. For example, you can define an abstract method in your page class. This means that this method MUST be defined in any object that extends it. So say you created the setPageAttributes () function as abstract in your page class. When you do this, you will create an empty function. When you create your index class, you must create the setPageAttributes () function (with the intention of populating it, for example, accessing the variables defined in the page class and using it to set the actual elements on the page, template, or you use), or you get a PHP error.

If you work with other people to get your project, abstract methods will tell the person: "Hey, you need to define these functions in any code that you write." This forced the application to be consistent.

Finally, you cannot go into frameworks such as MVC formats unless you do OOP. Although there is no need to go into MVC, and there is some debate, it highlights all the components of the application and is necessary in environments where many people (designers, coders, marketing staff) work on the same code.

Answer 8

The accepted answer, apparently, neglected the fact that you can call functions based on the variable name, for example, in this example:

 function drive($the_car){ $the_car(); } 

Admittedly, in this case there should be a function for each car, but it is much more efficient than the proposed switch statement.

---

Additional variables can be provided easily as such:

 function operate($the_car,$action){ $the_car($action); } function ferrari($action){ switch($action){ case 'drive': echo 'Driving'; break; case 'stop': echo 'Stopped'; break; default: return; } } operate('ferrari','drive'); 

There is a switch statement here, but it provides additional functionality that was not in the original example, so it is not a contradiction.

Answer 9

The concept of OOP is used in PHP to protect code. Since all requests are written to the function file instead of the code file, so no one can easily crack our code. Therefore, it is better to use classes in PHP instead of writing requests directly.