OOP and PHP

NZ_Kiwis

so ive used OOP in .NET before, my question on this is: one you've created an object how do you keep it so you can reuse it all the time without having to create it time and time again

NogDog

If you are talking about persisting an object across multiple calls to the same web application, it's not something really native to PHP. You can serialize it and store it in session data or the DB, and I think there are tools out there for storing it in memory; but then I've never run across a need to do it, so I don't really know the details -- and am curious why you feel a need to do so?

sneakyimp

Yeah it's not clear if this is a scope question, or whether you want a static variable or whether you mean to persist a data object between subsequent page requests. As for the latter, I believe it's possible to do something like that with Memcache.

NZ_Kiwis

When I've used OOP in my .NET applications I create an object and it stays 'live' and I reuse many of the properties and procedures via various button clicks and other GUI interactions. This can include database updates.

Wondering how this works with web based applications.

laserlight

NZ_Kiwis wrote:
When I've used OOP in my .NET applications I create an object and it stays 'live' and I reuse many of the properties and procedures via various button clicks and other GUI interactions. This can include database updates.

When your user clicks on a button, you still have the same objects in memory. You might change them in some way, but in the end the fact that you are presenting a changed interface to the user in response to the button click does not affect the fact that you still have the application state at hand (unless you deliberately set out to wipe your application state after that button click).

NZ_Kiwis wrote:
Wondering how this works with web based applications.

HTTP is stateless: the client has to send some kind of consistent identification in order for the server to identify it as the same client across different requests, e.g., by storing a session id in a cookie. It is as if after sending the response to the user, the application state is cleared. State therefore has to be separately maintained across requests/responses, whether by caching it in memory (memcache, redis, sessions backed by such schemes that use in-memory backends) or by storing it in some kind of persistent database (mysql/postgresql/etc databases, redis, sessions backed by database or file backends). The contents of this state could be your objects in a serialised form, or perhaps the data underlying your objects could be stored in a normalised relational database and then extracted as needed.

sneakyimp

I'm still not sure exactly what you mean, but it sounds like you mean that you want some data object to persist between two distinct HTTP requests for the server. PHP doesn't really work this way. I would refer you again to Memcache. I think you will find that there's a bit of work involved but that you can in fact create data objects that persists between distinct page requests to the server. I'm not familiar with how .NET works in this respect so I can't say more. Perhaps you could post some code examples of what you'd like to accomplish?

NZ_Kiwis

So why does PHP OOP exist? what exactly is the benefit?

@ - yes I want the object to exist over two distinct HTTP requests.

Am I better off loading my object from items stored into a DATABASE and retrieve these and create a new object on every page load?

Can AJAX assist here? is AJAX able to send or call my class functions or procedures if it's 'include('object.php)' from my main page?

laserlight

NZ_Kiwis wrote:
So why does PHP OOP exist? what exactly is the benefit?

The same general reason why OOP exists: it is a programming paradigm that can be sensibly used to model solutions to a variety of programming problems.

NZ_Kiwis wrote:
Am I better off loading my object from items stored into a DATABASE and retrieve these and create a new object on every page load?

Better off than what? The fact that HTTP is stateless has nothing to do with the programming paradigms that you use. You can use a functional programming language for serverside web programming and still have to deal with this problem. You can write a C program in procedural style for a desktop application and not have to deal with this problem (until you want to allow the user to save).

NZ_Kiwis wrote:
Can AJAX assist here? is AJAX able to send or call my class functions or procedures if it's 'include('object.php)' from my main page?

No, AJAX cannot help you here. In your PHP code that processes the AJAX requests, you still have to access storage that persists across HTTP requests if you want to work with an object created in response to a previous request.

NZ_Kiwis

Better off than storing in memchace

sneakyimp

NZ_Kiwis;11044463 wrote:
So why does PHP OOP exist? what exactly is the benefit?

There is plenty of reading you could do about this if you were only to do a little searching.

OOP does not mean 'persistent objects on the server.' OOP basically means programming with objects that you describe by defining classes. OOP is essentially an advancement over old-school procedural programming. It expands the idea of what programming is and introduces new types of data and functions beyond just plain old variables, constants, and functions. Basically it introduces the idea of classes. A class lets you define a bunch of related constants, variables, and functions and wrap them up in a tidy package. Why do this? It helps with code organization by clustering related functionality together and avoiding the often mind-bending difficulty of avoiding name collisions and organizing code.

NZ_Kiwis;11044463 wrote:
@ - yes I want the object to exist over two distinct HTTP requests.

As laserlight says, HTTP is a stateless protocol. Think of it as the server having amnesia. It will not remember you unless you remind it of who you are. You do this by using a session id. A session id is just some random token, usually a string of characters, that the server gives you to keep track of who is asking for what page. Every time you request a new page, you send the session id back to the server via COOKIE, GET, or POST so the server can look at it and continue from where you were during the previous request.

NZ_Kiwis;11044463 wrote:
Am I better off loading my object from items stored into a DATABASE and retrieve these and create a new object on every page load?

This is in fact how most PHP web applications work. A lot of most PHP frameworks' code is devoted to re-establishing all of the code context that needs to exist in order for the code to have a consistent environment for operation. The basic idea is that every time you request a page from a PHP server, the code has to go and connect to the database, look at your session id and see if you had a prior session, and then retrieve any data relevant to your session. Whether you are 'better off' or not is going to depend on the specifics I expect. You need to be more specific about what problem you are wrestling with.

NZ_Kiwis;11044463 wrote:
Can AJAX assist here? is AJAX able to send or call my class functions or procedures if it's 'include('object.php)' from my main page?

I do think AJAX can be of assistance in providing a consistent user experience, but only to a limited extent. Because JS runs on the client, AJAX functionality can be abused by malicious users if you rely on it too heavily. For instance, a clever user might change his JS variable has_administrator_privileges[/b] from FALSE to TRUE just by using a JS debugger. Your server better handle authentication properly to deny such users access to sensitive information. Basically, if it runs on the client, a bad guy can easily tamper with it.

NogDog

Before you go to a lot of effort to look into implementing such a thing, I'd just mildly warn against "premature optimization". While it is possible to use memcache or other technologies to create objects that persist across multiple HTTP requests, that does not necessarily mean that it's something you actually need to do, unless and until you identify that recreating that object on each request is a definite performance choke point that can be measurably and meaningfully improved by adding extra work and complexity to your application, not to mention additional dependencies. (I'd guesstimate that around 98% of performance issues I deal with on the job are dealt with via "EXPLAIN SELECT ...". 🙂 )

cretaceous

If it helps NZ kiwis I was under the same illusion as you - for me it dates back to when I first dabbled in OOP and 'persistent object' was how it was sold to me by the guy I was working with!

dalecosp

Persistent objects tend to have "save" and "restore" type operations, so they seem more persistent than they really are. I have objects in applications that persist for "quite a while" in one form or another, but since the lifetime of an HTTP transaction is quite short, the concept of persistence in objects isn't really that helpful.

I might be interested in knowing, purely for curiosity's sake, if the .NET paradigm included some sort of transparent "memory caching" without the need for programmer intervention; that might explain some things about this thread.

sneakyimp wrote:
OOP is essentially an advancement over old-school procedural programming.

s/essentially/potentially and I might agree :p

NogDog wrote:
Before you go to a lot of effort to look into implementing such a thing, I'd just mildly warn against "premature optimization". While it is possible to use memcache or

Yes, yes, and more yes. 🙂

Last thing --- I found this an interesting discussion: http://www.quora.com/Was-object-oriented-programming-a-failure

Weedpacket

dalecosp wrote:
Last thing --- I found this an interesting discussion:

That top reply by Church nails it for me. I'm going to have to archive that discussion.

One bit that stood out in it is his parenthetical comment that OO simultaneously encourages pseudo-Agile development (i.e., the sort of development process that real-world businesses call "Agile" because it's a fashionable buzzword) when what it requires to be effective is the design of a whole DSL (which would mean a lot of up-front no-output work from developers who might not even know what "DSL" means in this context).

So to deal with the complexity of the resulting smear you get your "architects", who may or may not have a clue and are the only ones who have any interaction with the people who want the job done in the first place breaking the job into pieces in whatever way they see fit and farming the pieces out to the codemonkeys who have no input into anything except making sure their piece does whatever it's supposed to.

Some of the other comments are also fair in making the distinction between the OOP Paradigm and its failings (lack of formal underpinning, for example), and OOP cargo cultism. We've seen some of that here, and it shows up in PHP's mailing lists (and bug tracker!) as proposals to make PHP more "object-oriented" that are no more than trivial syntactic tweaks that would turn foo($bar, $baz) into $bar->foo($baz) for certain types of $bar.

Bonesnap

OO PHP has always been an interesting subject for me. I find I run into way too many people who think it's the only way to go, or those who subscribe to the idea that OOP is "professional" (or at least more professional) than other approaches. I always like to counter that with a "professional" programmer recognizes that OOP is just a tool in a very large toolbox and would generally know when to use said tool over others, or when others may be more suitable. It's also interesting to see some of the reactions when it's mentioned that HTTP is a stateless protocol and objects must be recreated after every request. I have found that most people don't actually know that. While I don't think this is a reason not to use OO PHP, I find it interesting and something to consider.

Generally speaking I use OO PHP mostly as glorified associative arrays. From what I have read creating objects in PHP is cheap, and organizing a bunch of functions and properties/attributes into a "class" seems to make it worthwhile for myself in most situations. As such I tend to move away from using associative arrays and use the stdClass way more often now since my editor will use code intelligence to further help me. Classes also have the ability to extend/inherit which can make code organization more meaningful.

Just for the record I come from a .NET background as well so my first "taste" of OOP was much like OP's in that objects just seemed to persist, though my experience with .NET was with Windows applications and involved very little work with the web.

I can't help but find OOP discussions to be interesting; I love reading people's thoughts on the subject.

dalecosp

Weedpacket;11044505 wrote:
That top reply by Church nails it for me. I'm going to have to archive that discussion.

One bit that stood out in it is his parenthetical comment that OO simultaneously encourages pseudo-Agile development (i.e., the sort of development process that real-world businesses call "Agile" because it's a fashionable buzzword) when what it requires to be effective is the design of a whole DSL (which would mean a lot of up-front no-output work from developers who might not even know what "DSL" means in this context).

Chalk me up as one of those, albeit one who can use a search tool ...

So to deal with the complexity of the resulting smear you get your "architects", who may or may not have a clue and are the only ones who have any interaction with the people who want the job done in the first place breaking the job into pieces in whatever way they see fit and farming the pieces out to the codemonkeys who have no input into anything except making sure their piece does whatever it's supposed to.

Quite possibly yes, depending on the organization and its size. For a small operation, quite often the architects and code-monkeys are the same people.

Some of the other comments are also fair in making the distinction between the OOP Paradigm and its failings (lack of formal underpinning, for example), and OOP cargo cultism. We've seen some of that here, and it shows up in PHP's mailing lists (and bug tracker!) as proposals to make PHP more "object-oriented" that are no more than trivial syntactic tweaks that would turn foo($bar, $baz) into $bar->foo($baz) for certain types of $bar.

And that's the real issue; an insistence that everything we do would be better if it was OO, and that changing the way the code is written will change the logic used to design the code in the first place, which isn't how I do things (at least, most of the time...)

Bonesnap;11044611 wrote:
OO PHP has always been an interesting subject for me. I find I run into way too many people who think it's the only way to go, or those who subscribe to the idea that OOP is "professional" (or at least more professional) than other approaches. I always like to counter that with a "professional" programmer recognizes that OOP is just a tool in a very large toolbox and would generally know when to use said tool over others, or when others may be more suitable. It's also interesting to see some of the reactions when it's mentioned that HTTP is a stateless protocol and objects must be recreated after every request. I have found that most people don't actually know that. While I don't think this is a reason not to use OO PHP, I find it interesting and something to consider.

Generally speaking I use OO PHP mostly as glorified associative arrays. From what I have read creating objects in PHP is cheap, and organizing a bunch of functions and properties/attributes into a "class" seems to make it worthwhile for myself in most situations. As such I tend to move away from using associative arrays and use the stdClass way more often now since my editor will use code intelligence to further help me. Classes also have the ability to extend/inherit which can make code organization more meaningful.

Just for the record I come from a .NET background as well so my first "taste" of OOP was much like OP's in that objects just seemed to persist, though my experience with .NET was with Windows applications and involved very little work with the web.

I can't help but find OOP discussions to be interesting; I love reading people's thoughts on the subject.

The best use I've found for OOP practices in PHP is when my code is dealing with things that are concrete, and fairly simple, objects in real-life. That could include almost anything that can be categorized as an object, but there's too much opportunity for overkill to throw in a blanket statement that OOP is always the best way. For example, a web page that gathers email addresses to add to a mailing list DB? You could create a large Person class, but what's the point if it isn't ever going to do anything but collect two names and an email address?

laserlight

Weedpacket wrote:
it shows up in PHP's mailing lists (and bug tracker!) as proposals to make PHP more "object-oriented" that are no more than trivial syntactic tweaks that would turn foo($bar, $baz) into $bar->foo($baz) for certain types of $bar.

dalecosp wrote:
And that's the real issue; an insistence that everything we do would be better if it was OO, and that changing the way the code is written will change the logic used to design the code in the first place, which isn't how I do things (at least, most of the time...)

If merely introducing syntactic sugar makes something "object oriented", then it was "object oriented" to begin with. However, that does not mean that syntactic sugar is necessarily bad, but rather that if your argument is "this makes it object oriented, so it must be good!", then you have a poor argument that misses both object oriented design and the more circumspect value that the syntactic sugar actually adds.

dalecosp wrote:
The best use I've found for OOP practices in PHP is when my code is dealing with things that are concrete, and fairly simple, objects in real-life. That could include almost anything that can be categorized as an object, but there's too much opportunity for overkill to throw in a blanket statement that OOP is always the best way. For example, a web page that gathers email addresses to add to a mailing list DB? You could create a large Person class, but what's the point if it isn't ever going to do anything but collect two names and an email address?

The problem here has to do with the large Person class: you're probably over-engineering if you do that, especially for this example task. But if you introduce a Person class with a minimal but complete interface (and internals) to do this, then there's a good point: you have an abstraction that could help a reader understand the code, even though the class is never used anywhere else. Or, you could forgo the class and write say, a few functions to do the job, handling the name parts and email address together but as separate entities: this is good because again, you have abstractions (the functions) that could help a reader understand the code, even if those functions are never used anywhere else.