TechTips: Why use classes and objects in PHP? 
Author Message
 TechTips: Why use classes and objects in PHP?

PHP is an interesting language in that, while it provides a fairly robust
"object" model, it does not force the same upon you.  You can create a very
nice procedural-logic program with it using nothing but global variables
and independent procedures.  So, in a few words, /why/ should you want to
use classes and objects in your next design?

I think that there are three main reasons to use objects and classes:

        (1)     Encapsulating memory.
        (2)     Encapsulating procedural logic.
        (3)     Encapsulating /bugs!/

ENCAPSULATING MEMORY:
An "object" is a collection of /data/ (the "vars" that are declared within
the object's definition), and /programming/ (the "methods" that are also
declared within the object).  Each of these are well-isolated from "that
which is not part of this object."  Objects are the closest thing in PHP
that may be compared to the "record" or "struct" concepts in other
programming languages.

ENCAPSULATING PROCEDURAL LOGIC:
As noted, an object contains both data and procedural-code.  This allows you
to "hide" details of how an object is supposed to work, because the data
and the code that is supposed to work with that data are tightly bound
together into one "thing."  

Furthermore, classes and objects make it much easier to /expand/ upon those
procedural definitions in an easily-controlled way, without re-stating
them.  A class can be defined as a "descendent" of an existing class, which
simply means that "it's just like such-and-such class /except/ for the
following differences, to wit..."  The differences between objects of the
two classes are /invisible/ to the _users_ of the objects.

This last notion is particularly important!  After all, the /users/ of an
object don't really /care/ how it works.  They should not have to.  There
should be nothing at all in the "user of an object" code that would have to
be different; not at all.

ENCAPSULATING BUGS(!):
One of the nicest things in the world is to "fix a bug and /know/ that it is
fixed everywhere."  That no matter how and where a particular piece of code
is used, there's nothing out there that would be exposed to the effects
(known to the programmer, or unknown) of the change:  because there /are/
no "effects" of the change.

If the definition -- or "implementation" -- of an object really /is/ this
clean, then there's a very sharp dividing-line between "how it works"
(known only to the object's implementation, and buggy, and now-fixed) and
"what it does."

In programs written by anyone other than students of the craft, there are
rarely errors in "what it does."  (Expansions over time, perhaps, but
rarely original-errors.)  The bugs crop up ... not so much in the original
implementation, but in /side/ /effects/ between the "implementation" and
"usage" code.  Programmers write stuff that's dependent upon /how/ a
particular piece of code works... they write it and forget about it, and in
so doing they create a _functional_ _dependency_ that comes back to "bite"
them later.

When you design with objects and classes, you start putting fences and
dividing-lines around sections of your program ... dividing-lines and
fences that "really do 'stick.'"  You'll discover that the programs you're
writing /do/ become much more robust:  that you spend a lot less time
debugging them, and a lot less time worrying that /users/ will discover
bugs that you didn't catch in your testing.



Mon, 30 May 2005 11:58:51 GMT  
 TechTips: Why use classes and objects in PHP?
thanks for that info very interesting


Quote:

> PHP is an interesting language in that, while it provides a fairly robust
> "object" model, it does not force the same upon you.  You can create a
very
> nice procedural-logic program with it using nothing but global variables
> and independent procedures.  So, in a few words, /why/ should you want to
> use classes and objects in your next design?

> I think that there are three main reasons to use objects and classes:

>         (1)     Encapsulating memory.
>         (2)     Encapsulating procedural logic.
>         (3)     Encapsulating /bugs!/

> ENCAPSULATING MEMORY:
> An "object" is a collection of /data/ (the "vars" that are declared within
> the object's definition), and /programming/ (the "methods" that are also
> declared within the object).  Each of these are well-isolated from "that
> which is not part of this object."  Objects are the closest thing in PHP
> that may be compared to the "record" or "struct" concepts in other
> programming languages.

> ENCAPSULATING PROCEDURAL LOGIC:
> As noted, an object contains both data and procedural-code.  This allows
you
> to "hide" details of how an object is supposed to work, because the data
> and the code that is supposed to work with that data are tightly bound
> together into one "thing."

> Furthermore, classes and objects make it much easier to /expand/ upon
those
> procedural definitions in an easily-controlled way, without re-stating
> them.  A class can be defined as a "descendent" of an existing class,
which
> simply means that "it's just like such-and-such class /except/ for the
> following differences, to wit..."  The differences between objects of the
> two classes are /invisible/ to the _users_ of the objects.

> This last notion is particularly important!  After all, the /users/ of an
> object don't really /care/ how it works.  They should not have to.  There
> should be nothing at all in the "user of an object" code that would have
to
> be different; not at all.

> ENCAPSULATING BUGS(!):
> One of the nicest things in the world is to "fix a bug and /know/ that it
is
> fixed everywhere."  That no matter how and where a particular piece of
code
> is used, there's nothing out there that would be exposed to the effects
> (known to the programmer, or unknown) of the change:  because there /are/
> no "effects" of the change.

> If the definition -- or "implementation" -- of an object really /is/ this
> clean, then there's a very sharp dividing-line between "how it works"
> (known only to the object's implementation, and buggy, and now-fixed) and
> "what it does."

> In programs written by anyone other than students of the craft, there are
> rarely errors in "what it does."  (Expansions over time, perhaps, but
> rarely original-errors.)  The bugs crop up ... not so much in the original
> implementation, but in /side/ /effects/ between the "implementation" and
> "usage" code.  Programmers write stuff that's dependent upon /how/ a
> particular piece of code works... they write it and forget about it, and
in
> so doing they create a _functional_ _dependency_ that comes back to "bite"
> them later.

> When you design with objects and classes, you start putting fences and
> dividing-lines around sections of your program ... dividing-lines and
> fences that "really do 'stick.'"  You'll discover that the programs you're
> writing /do/ become much more robust:  that you spend a lot less time
> debugging them, and a lot less time worrying that /users/ will discover
> bugs that you didn't catch in your testing.



Mon, 30 May 2005 18:42:48 GMT  
 TechTips: Why use classes and objects in PHP?
On Wed, 11 Dec 2002 20:58:51 -0700, Sundial Services

Quote:

>PHP is an interesting language in that, while it provides a fairly robust
>"object" model, it does not force the same upon you.  You can create a very
>nice procedural-logic program with it using nothing but global variables
>and independent procedures.  So, in a few words, /why/ should you want to
>use classes and objects in your next design?

>I think that there are three main reasons to use objects and classes:

>        (1)     Encapsulating memory.
>        (2)     Encapsulating procedural logic.
>        (3)     Encapsulating /bugs!/

Here's a question: should I feel guilty for writing a class that
consists of all my favorite functions (essentially a snippet class)?
--



Tue, 31 May 2005 01:22:45 GMT  
 TechTips: Why use classes and objects in PHP?

Quote:

> Here's a question: should I feel guilty for writing a class that
> consists of all my favorite functions (essentially a snippet class)?

Not if you officially call it a "utility class" ;)
This is actually a "better" [organizationally speaking] way of packaging
your utility functions because it effectively gives them their own
namespace, separating them from core stuff.

--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.



Tue, 31 May 2005 01:22:57 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. FW: [PHP Classes] MetaL - a XML based meta-programming language developed using PHP

2. Module rfc822 - uses file-objects - why?

3. Using external classes in Object Rexx

4. using object class with pointers in gant

5. Newbie: classes, objects, using methods problem

6. Why can't I INITIALIZE a class variable with another class var

7. class object access in class definition?

8. Why object.__getattribute__ and not object.__getattr__ ?

9. why why why oh why why baby

10. Class objects , instance objects

11. orx - class objects as object managers ?

12. The use of the Factory Paragraph versus Class-Object in Object Oriented (OO) COBOL

 

 
Powered by phpBB® Forum Software