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
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
[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