The Point of OOP PHP?

[Berislav Lopac]

I have a some experience in OOP, primarily with Java and JavaScript, and a
little with PHP4. I have just checked some texts about upcoming PHP5
features, and particularly the OOP ones, and there is something that puzzles
me.

Although OOP is a great way to program and especially to keep your code and
design neat and easy to update, I still see PHP as a procedure-oriented
language, and don't see what is to be gained by introducing the plethora of
OOP features. I mean, PHP is (primarily) used for server-client HTTP-based
applications, where on each HTTP request the script is evaluated, parsed and
performed again. Even if we put all our code into a single PHP file (which
is a common practice) and the code is cached to speed things up, we still
have a blank slate each time the file is called, and we have to resend all
the values.

In my opinion, one of the points of OOD is to have a bunch of objects which,
once constructed, exist in some sort of "virtual reality" and interact with
each other, sending each other messages and changing each other's states.
Web's architecture is not the perfect environment for this approach, but it
can be done the way it is with JSP, where we can have persistent JavaBeans,
which interact with HTTP requests as if they were other objects.

I might have misunderstood the concepts behing PHP5 and Zend Engine 2, but I
don't see buch point in OOP approach if an object exists only while a script
is being executed. I would like to hear any clarifications, as well as other
people's others opinions on that subject.

Best regards,

Berislav

[Tom Thackrey]

On 13-Jan-2004, "Berislav Lopac" <be************@dimedia.hr> wrote:

I have a some experience in OOP, primarily with Java and JavaScript, and a
little with PHP4. I have just checked some texts about upcoming PHP5
features, and particularly the OOP ones, and there is something that
puzzles
me.

Although OOP is a great way to program and especially to keep your code
and
design neat and easy to update, I still see PHP as a procedure-oriented
language, and don't see what is to be gained by introducing the plethora
of
OOP features. I mean, PHP is (primarily) used for server-client HTTP-based
applications, where on each HTTP request the script is evaluated, parsed
and
performed again. Even if we put all our code into a single PHP file (which
is a common practice) and the code is cached to speed things up, we still
have a blank slate each time the file is called, and we have to resend all
the values.

In my opinion, one of the points of OOD is to have a bunch of objects
which,
once constructed, exist in some sort of "virtual reality" and interact
with
each other, sending each other messages and changing each other's states.
Web's architecture is not the perfect environment for this approach, but
it
can be done the way it is with JSP, where we can have persistent
JavaBeans,
which interact with HTTP requests as if they were other objects.

I might have misunderstood the concepts behing PHP5 and Zend Engine 2, but
I
don't see buch point in OOP approach if an object exists only while a
script
is being executed. I would like to hear any clarifications, as well as
other
people's others opinions on that subject.

PHP sessions allow for objects to persist between 'pages'. They can also be
serialized to a database or file which even allows for object sharing
between 'clients'. I guess I don't see the problem.
--
Tom Thackrey
www.creative-light.com
tom (at) creative (dash) light (dot) com
do NOT send email to ja*********@willglen.net (it's reserved for spammers)

[Jochen Buennagel]

Berislav Lopac wrote:

I might have misunderstood the concepts behing PHP5 and Zend Engine 2, but I
don't see buch point in OOP approach if an object exists only while a script
is being executed. I would like to hear any clarifications, as well as other
people's others opinions on that subject.

The point of OOP is not to have application level objects that stay
around between requests. That is just a useful additional feature of
some languages like Java when used in a web environment.

If you're writing programs that go beyond a simple one-page-one-response
level, you want to structure your programs in a flexible, extensible,
reusable manner, maybe use design patterns and refactoring, and OOP
enables you to do that.

Just my 2c

Jochen

[Kevin Thorpe]

I totally agree with you - for simple applications OOP is of little use.

However it comes into play as things get more complex.

For larger applications I tend to write a class library encompassing
most of the application structure, abstracting the database layer and
prsenting a simple set of objects to my procedural pages. This is of use
even if the objects aren't persistent.

When you then add session support to that your objects are persistent
from page to page. Then OOP really comes into its own.

[Berislav Lopac]

Kevin Thorpe wrote:

I totally agree with you - for simple applications OOP is of little
use.

However it comes into play as things get more complex.

For larger applications I tend to write a class library encompassing
most of the application structure, abstracting the database layer and
prsenting a simple set of objects to my procedural pages. This is of
use even if the objects aren't persistent.

When you then add session support to that your objects are persistent
from page to page. Then OOP really comes into its own.

However, it is still impossible to create application-wide objects like it
is possible with JavaBeans -- a new object is always re-created for each new
session. It is possible to save any changes in its state to database or a
config file, but then the application should check it on every request,
which makes it meaningless.

Berislav

[Kevin Thorpe]

Berislav Lopac wrote:

Kevin Thorpe wrote:

I totally agree with you - for simple applications OOP is of little
use.

However it comes into play as things get more complex.

For larger applications I tend to write a class library encompassing
most of the application structure, abstracting the database layer and
prsenting a simple set of objects to my procedural pages. This is of
use even if the objects aren't persistent.

When you then add session support to that your objects are persistent
from page to page. Then OOP really comes into its own.

However, it is still impossible to create application-wide objects like it
is possible with JavaBeans -- a new object is always re-created for each new
session. It is possible to save any changes in its state to database or a
config file, but then the application should check it on every request,
which makes it meaningless.

Sessions do that internally for you. The default session handler
serializes(sic) any variables and objects in $_SESSION to a disk file
and restores them for your next page. It's completely possible to
replace the handler with one that keeps the objects live (usually by
having a session server to hold the actual objects). In practice there's
no difference to your application.

[Berislav Lopac]

Kevin Thorpe wrote:

Berislav Lopac wrote:

However, it is still impossible to create application-wide objects
like it is possible with JavaBeans -- a new object is always
re-created for each new session. It is possible to save any changes
in its state to database or a config file, but then the application
should check it on every request, which makes it meaningless.

Sessions do that internally for you. The default session handler
serializes(sic) any variables and objects in $_SESSION to a disk file
and restores them for your next page. It's completely possible to
replace the handler with one that keeps the objects live (usually by
having a session server to hold the actual objects). In practice
there's no difference to your application.

I think I didn't explain clearly enough what I head in mind. By
application-wide objects I mean those that are active as long as the
application (basically, the Web server) is up, and each visitor interacts
with the exact same object (through references). That is virtually
impossible in PHP4, where you copy objects instead of references on
returning etc., but PHP5 is supposed to have a Java-like ability to return
references to objects by default.

This makes possible that system-wide preferences are always reachable as
objects, and as soon as an object's state is changed, all the following
requests will recognize the new state, without relying on databases or
serialization.

Berislav

[Phil Roberts]

With total disregard for any kind of safety measures "Berislav
Lopac" <be************@dimedia.hr> leapt forth and uttered:

However, it is still impossible to create application-wide
objects like it is possible with JavaBeans

Thats because PHP is not Java.

Just because PHP can't do everything Java is capable of does not
render the fundamental concepts of object-orientation useless.

--
There is no signature.....

[Jason G]

I am the lead designer on a project that consists of roughly 5000
source files, and a 60,000,000 row database (~ 6 gb) with about 200
tables.

We have VERY successfully used the limited oop features of php4 to
abstract and centralize portions of our code, for instance:

CMySQLConnection is a class that connects to mysql and provides
methods such as $oConnection->
GetRow()
GetValue()
GetObject()
GetArray()
GetObjectArray()
GetResultObject()
etc...

We have a CSession class that is extended into CAdminSession and
CMemberSession with methods such as $oSession->
CheckSession()
RequireSession()
GetUserID()
GoHome()
GetVar()
SetVar()
SaveVars() (will implement this in a destructor in php5)

Also we use classes such as CContact CCustomer CMember CAdmin
CAuthorizeNetInterface CEmailSystem CBillingSystem, CAdminPage,
CMemberPage, etc...

All in all, OOP has allowed us a great way to program in a complex
enviroment and reuse our code. The session handling is a good
example. We have a CSession base class, and when we need a session
setup, we extend another class from CSession and override 2 methods
(the constructor and ValidateUser).

It may not emulate all of the features of Java, but then again if you
wanted that, prehaps you should just use Java. OOP is a great way to
organize and code large projects.

Sincerely,

Jason Garber
Chief Technology Officer
IonZoft, Inc.



"Berislav Lopac" <be************@dimedia.hr> wrote in message news:<bu**********@ls219.htnet.hr>...

Kevin Thorpe wrote:

Berislav Lopac wrote:

However, it is still impossible to create application-wide objects
like it is possible with JavaBeans -- a new object is always
re-created for each new session. It is possible to save any changes
in its state to database or a config file, but then the application
should check it on every request, which makes it meaningless.

Sessions do that internally for you. The default session handler
serializes(sic) any variables and objects in $_SESSION to a disk file
and restores them for your next page. It's completely possible to
replace the handler with one that keeps the objects live (usually by
having a session server to hold the actual objects). In practice
there's no difference to your application.

I think I didn't explain clearly enough what I head in mind. By
application-wide objects I mean those that are active as long as the
application (basically, the Web server) is up, and each visitor interacts
with the exact same object (through references). That is virtually
impossible in PHP4, where you copy objects instead of references on
returning etc., but PHP5 is supposed to have a Java-like ability to return
references to objects by default.

This makes possible that system-wide preferences are always reachable as
objects, and as soon as an object's state is changed, all the following
requests will recognize the new state, without relying on databases or
serialization.

Berislav