Re: [PHP] class/object design
Hi Chris
I am currently busy with a similar experiment for a project of my own and my
OOP knowledge is similarly limited :). I have had a fair degree of success
(by my humble standards) and I am currently trying to make the process as
session-friendly as possible. I have a single class (call it Class A) that
is used to track db connections and certain environment variables (e.g. user
name and id). When I construct other classes (Class B, Class CClass n)
that are specific to only portions of my application I pass Class A to these
lower classes via their constructor.
My problem is : If I make changes to my instance of A, after B or C is
instantiated, I have to manually reset B or C so that they reflect the
changes to A whereas I would prefer some sort of pass_by_reference mechanism
that would give each instance of B and C a pointer to the instance of A, so
that they would be automatically updated. Because I am stubborn, I am going
to try and solve this myself before I post a Please Help to the list, but
I would be happy to compare notes with you (or anyone else) offlist if you
so wish.
Regards
Rory McKinley
Nebula Solutions
+27 82 857 2391
[EMAIL PROTECTED]
There are 10 kinds of people in this world,
those who understand binary and those who don't (Unknown)
- Original Message -
From: Chris W. Parker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 1:51 AM
Subject: [PHP] class/object design
Hey peeps.
Let me try to make this simple. Right now I have a base db class that is
moved solely for interacting with the db. It opens the connection, runs
queries, and returns the results of those queries. Along with this class
I've got some other classes (I'll call them upper classes) that are
used to interact with different aspects of my project. For example I've
got a Products class (used to add/delete products, etc.) and a Category
class (used to add/delete categories, etc.).
Currently I'm extending the base db class into these upper classes.
i.e.
class DB
{
function dostuff ()
{
}
}
class Products extends DB
{
function dothings ()
{
$this-dostuff();
}
}
On this list I read a post that suggested I not do it this way but
instead instantiate a DB object within each method of the upper class
whenever necessary (as far as I understood the recommendation).
This sounds like a good idea except that this would mean I'd be creating
and destroying a DB object each time a method in an upper class needed
to access the db. The way I'm doing it now requires that I only
instantiate one object for the entire page and let any method in that
upper class to share the connection.
With my limited knowledge of OOP the only solution I can see would be to
use a constructor in the upper class to instantiate the object when
the upper class object is instantiated.
Am I making sense and does anyone have any suggestions or comments to
add? Maybe something to straighten me out?
Thanks,
Chris.
--
Don't like reformatting your Outlook replies? Now there's relief!
http://home.in.tum.de/~jain/software/outlook-quotefix/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] class/object design
Hey peeps.
Let me try to make this simple. Right now I have a base db class that is
moved solely for interacting with the db. It opens the connection, runs
queries, and returns the results of those queries. Along with this class
I've got some other classes (I'll call them upper classes) that are
used to interact with different aspects of my project. For example I've
got a Products class (used to add/delete products, etc.) and a Category
class (used to add/delete categories, etc.).
Currently I'm extending the base db class into these upper classes.
i.e.
class DB
{
function dostuff ()
{
}
}
class Products extends DB
{
function dothings ()
{
$this-dostuff();
}
}
On this list I read a post that suggested I not do it this way but
instead instantiate a DB object within each method of the upper class
whenever necessary (as far as I understood the recommendation).
This sounds like a good idea except that this would mean I'd be creating
and destroying a DB object each time a method in an upper class needed
to access the db. The way I'm doing it now requires that I only
instantiate one object for the entire page and let any method in that
upper class to share the connection.
With my limited knowledge of OOP the only solution I can see would be to
use a constructor in the upper class to instantiate the object when
the upper class object is instantiated.
Am I making sense and does anyone have any suggestions or comments to
add? Maybe something to straighten me out?
Thanks,
Chris.
--
Don't like reformatting your Outlook replies? Now there's relief!
http://home.in.tum.de/~jain/software/outlook-quotefix/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] class/object design
On Tue, 2003-10-14 at 19:51, Chris W. Parker wrote:
Hey peeps.
Let me try to make this simple. Right now I have a base db class that is
moved solely for interacting with the db. It opens the connection, runs
queries, and returns the results of those queries. Along with this class
I've got some other classes (I'll call them upper classes) that are
used to interact with different aspects of my project. For example I've
got a Products class (used to add/delete products, etc.) and a Category
class (used to add/delete categories, etc.).
Currently I'm extending the base db class into these upper classes.
i.e.
class DB
{
function dostuff ()
{
}
}
class Products extends DB
{
function dothings ()
{
$this-dostuff();
}
}
On this list I read a post that suggested I not do it this way but
instead instantiate a DB object within each method of the upper class
whenever necessary (as far as I understood the recommendation).
This sounds like a good idea except that this would mean I'd be creating
and destroying a DB object each time a method in an upper class needed
to access the db. The way I'm doing it now requires that I only
instantiate one object for the entire page and let any method in that
upper class to share the connection.
With my limited knowledge of OOP the only solution I can see would be to
use a constructor in the upper class to instantiate the object when
the upper class object is instantiated.
Am I making sense and does anyone have any suggestions or comments to
add? Maybe something to straighten me out?
It's not so much don't do it as much as it is a case of you'll
probably run into problems later if your application gets much bigger.
By extending the database class you tightly couple your product class
with that of the database class. That can be ok, but in the case of
products, are they really that related to your database? As you say
instantiating an instance of the database connection everytime you want
to make a query is probably not a good solution either, although it
ensures that you get a clean connection and that your product class is
not dependent on the DB class. To overcome this issue your DB class can
implement some kind of pooling system. In other words for any given
request for a connection, you can see if a connection was created
previously and if so, and if freed return it. Otherwise if none are free
then you create a new connection, add it to the pool, then return it.
generally speaking you'll find that very few actual connections are made
using a pool like this.
HTH,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
