[web] OO in PHP
Author
I'm self taught in PHP, and I've never used classes/oo before. I am familiar with them, I just don't use them. Furthermore, for smaller projects, I do not see a need for object oriented programming other than trying to develop/keep good habits. Is this a true statement, or does the use of classes, etc somehow increase performance in a way I am not aware of.
Quote:Does the use of classes, etc somehow increase performance in a way I am not aware of?
No. But it helps to write reusable and more maintainable code. Also, some OO tricks allow you to do some pretty useful tricks that would be hard to do when writing procedural code. But you should only use OO where it makes sense. I think my code is about 50/50 OO and procedural.
Personally, I can't wait for mixins (multiple inheritance).
At one point I was a straight up procedural programmer in PHP. My code looked something like:
There would be a news/add.php page, a news/edit.php page, etc. All was well because, after all, it was just a single, small site and easy to maintain.
But that grew into a few small sites and then a large site, and then more and more. I would copy/paste as best I could, but after years of that, it becomes too hard to handle and the differences between sites make it hard to share code.
Now I work with a complete OOP framework I wrote from the bottom up that focuses on reusing code modules across every site. Every site I create and host operates on the same exact codebase. The above code might look more like:
Then that would render a template page:
There are lots of different ways to handle this, and it's not necessarily an OOP vs non-OOP idea. That is, you could do this without any OOP if you really didn't want to use it.
But the point is that there is a clean separation between everything. Sites can share the code modules among themselves easily and, if necessary, extend the classes to provide minor modifications. Then the template pages can easily be changed per website to give whatever look they want; as an added bonus, template pages are able to include any read-only data that is defined for the site, so pages can really be quite unique.
In other words, it's not about using OOP to "increase the performance," it's about having some sort of methodology that allows you to easily maintain and reuse your code forever. You can always buy a faster computer, but you'll never be able to get back the time you waste redoing the same sort of thing over and over again due to a lack of planning.
require_once('common.inc.php');$news = $db->getAll("SELECT * FROM news_item ORDER BY dt DESC LIMIT 10");include('header.inc.php');?><ul> <?foreach ($news as $n):?> <li> <h1><?=$n[title']?></h1> <p><?=$n['description']?></h1> </li> <?endforeach;?></ul>include('footer.inc.php');There would be a news/add.php page, a news/edit.php page, etc. All was well because, after all, it was just a single, small site and easy to maintain.
But that grew into a few small sites and then a large site, and then more and more. I would copy/paste as best I could, but after years of that, it becomes too hard to handle and the differences between sites make it hard to share code.
Now I work with a complete OOP framework I wrote from the bottom up that focuses on reusing code modules across every site. Every site I create and host operates on the same exact codebase. The above code might look more like:
class Module_News { public function requestHandler(HTTPRequest $req) { if ($req->path = '/news') { $tpl->news = News::fetchRecent(); return $tpl->render('News/index'); } } }Then that would render a template page:
<ul> <li tpl:loop="n; news"> <h1>{n.title}</h1> <p>{n.description}</p> </li></ul>There are lots of different ways to handle this, and it's not necessarily an OOP vs non-OOP idea. That is, you could do this without any OOP if you really didn't want to use it.
But the point is that there is a clean separation between everything. Sites can share the code modules among themselves easily and, if necessary, extend the classes to provide minor modifications. Then the template pages can easily be changed per website to give whatever look they want; as an added bonus, template pages are able to include any read-only data that is defined for the site, so pages can really be quite unique.
In other words, it's not about using OOP to "increase the performance," it's about having some sort of methodology that allows you to easily maintain and reuse your code forever. You can always buy a faster computer, but you'll never be able to get back the time you waste redoing the same sort of thing over and over again due to a lack of planning.
I agree with the OOP idea. I have a couple of purely procedural modules that I wish now had been written as objects. It will be a lot of work to convert them, but I'm spending a lot of time dealing with stupid things that a better design would eliminate.
I've written something like 30k+ lines of PHP not including HTML and hundreds of templates on my current job/project. I designed and built the whole thing from the ground up. When i started, i was intent on doing everything OOP. However, when you throw in 1) a database, and 2) a stateless transaction-based system (a web server), things get ugly for OOP.
Now for some things, it makes perfect sense. You can bet i have dedicated User, Database, and Page classes. Those a really handy in OOP. But some things are really bad in OOP when there is a Database. For instance, lists of objects. If you do it the pure OOP way, each object would load itself from the DB. But if you have hundreds of objects in a list, you are making hundreds of DB calls. So you have to "break encapsulation" to some extent and go procedural for efficiency's sake. I've learned that's okay!
So use procedural when it works best and OOP when it works best.
But if it wasn't on a web server and it didn't need a DB, i'd OOP the snot out of it.
Now for some things, it makes perfect sense. You can bet i have dedicated User, Database, and Page classes. Those a really handy in OOP. But some things are really bad in OOP when there is a Database. For instance, lists of objects. If you do it the pure OOP way, each object would load itself from the DB. But if you have hundreds of objects in a list, you are making hundreds of DB calls. So you have to "break encapsulation" to some extent and go procedural for efficiency's sake. I've learned that's okay!
So use procedural when it works best and OOP when it works best.
But if it wasn't on a web server and it didn't need a DB, i'd OOP the snot out of it.
Procedural programming is something that I absolutely abhor, because of its intrinsic global state. However, Object-Oriented development is often too clunky to be of any interest. Which is why I use functional programming techniques when I design web sites.
Of course, since web design languages generally don't support closures, I have to emulate them using objects, and sometimes inheritance-like schemes prove interesting because there are no variant types either. However, even if the implementation uses object-oriented techniques, the overall design remains functional.
For instance, I don't have a 'database object'. I have a 'persistent association' data type which supports targeted extraction of an element, filtering, reducing and mapping. All of these are implemented and optimized in an opaque way using first-class functions to interact with an underderlying database. Applying an operation to every object in the association thus involves a single query, instead of the many queries required in non-functional code.
The underlying philosophy of my code is to design a generic library without a single hardcoded reference to what database or table should be used (instead, the database and tables are passed as arguments to any objects which need persistent storage), no reference to what the output should be like (beyond a purely semantic XML-level that can then be translated by any means seen fit into clean HTML-javascript-CSS) or where it should be sent, and no reference to what the input should be like (post, get, cookies, requests saved to database, and so on). The core system also uses exactly zero global variables.
Then, once the library is designed, I write a single configuration file which defines what the database looks like, how the output looks like and where it is sent, and where the input comes from. In essence, the configuration describes the entire functionality of the server in single file using the library. Individual scripts then include that file to define all the server objects, and then use these objects to perform their work. For instance, I have a text-editor page which consists in a first function call with 8 arguments: internationalization text, rights manager, current user identifier, the 'get' and 'post' associative arrays, the target peristent association to store edited text, the current language, and the url of the script being executed; this function returns an XML tree which is then passed to a format-XML-and-send-to-user function designed for that purpose. If I wanted, I could thus use the text editor in a project with completely different settings and still have it work.
Of course, since web design languages generally don't support closures, I have to emulate them using objects, and sometimes inheritance-like schemes prove interesting because there are no variant types either. However, even if the implementation uses object-oriented techniques, the overall design remains functional.
For instance, I don't have a 'database object'. I have a 'persistent association' data type which supports targeted extraction of an element, filtering, reducing and mapping. All of these are implemented and optimized in an opaque way using first-class functions to interact with an underderlying database. Applying an operation to every object in the association thus involves a single query, instead of the many queries required in non-functional code.
The underlying philosophy of my code is to design a generic library without a single hardcoded reference to what database or table should be used (instead, the database and tables are passed as arguments to any objects which need persistent storage), no reference to what the output should be like (beyond a purely semantic XML-level that can then be translated by any means seen fit into clean HTML-javascript-CSS) or where it should be sent, and no reference to what the input should be like (post, get, cookies, requests saved to database, and so on). The core system also uses exactly zero global variables.
Then, once the library is designed, I write a single configuration file which defines what the database looks like, how the output looks like and where it is sent, and where the input comes from. In essence, the configuration describes the entire functionality of the server in single file using the library. Individual scripts then include that file to define all the server objects, and then use these objects to perform their work. For instance, I have a text-editor page which consists in a first function call with 8 arguments: internationalization text, rights manager, current user identifier, the 'get' and 'post' associative arrays, the target peristent association to store edited text, the current language, and the url of the script being executed; this function returns an XML tree which is then passed to a format-XML-and-send-to-user function designed for that purpose. If I wanted, I could thus use the text editor in a project with completely different settings and still have it work.
Coming from a C++ background, I use OOP with PHP5 almost exclusivly. The benefits are to great to ignore. Reusablility, encapsulation, inheritance, greater readability etc.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
